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ABSTRACT 


Current modeling and simulation techniques may not adequately represent military operations 
using unmanned aircraft systems (UAS). A method to represent these conditions in a combat 
model can offer insight to the use and application of UAS operations, as well as understand¬ 
ing the sensitivity of simulation outcomes to the variability of UAS performance. Additionally, 
using combat model simulations that do not represent UAS behavior and conditions that cause 
this variability may return misleading or incomplete results. Current approaches include explicit 
scripting of behaviors and events. We develop a proof of principle search, targeting, and acqui¬ 
sition (STA) model for use with UAS within COMBATXXI, leveraging existing STA research 
conducted at the MOVES Institute at the Naval Postgraduate School. These dynamic behaviors 
are driven by events as they unfold during the simulation run rather than relying on preplanned 
events as in the scripted approach. This allows these behaviors to be highly reusable since they 
do not contain scenario or incident specific information. We demonstrate the application of the 
new STA model in a tactical convoy scenario in COMBATXXI. A design of experiments and 
post analysis quantifies the sensitivity of the measures of effectiveness of success to conditions 
contributing to variability in UAS performance. 
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Executive Summary 


Current modeling and simulation techniques may not adequately represent military operations 
in respect to unmanned aircraft systems (UAS), to include the unmanned aerial vehicle (UAV) 
and its human operator. The performance of a UAS in the field can vary greatly, and this per¬ 
formance can have an enormous affect on the outcome of a military operation. This complex 
and variable behavior may be sensitive to considerations not represented in contemporary com¬ 
bat models. These conditions can include, but are not limited to, pilot training and experience. 
Combat models may require a means to model the effects of this behavior, particularly when an¬ 
alyzing the skill or efficiency of a UAS in providing information to other entities in the scenario. 


A method to represent these conditions in a combat model can offer insight to the use and ap¬ 
plication of UAS in operations, as well as understanding the sensitivity of simulation outcomes 
to the variability of UAS performance. Additionally, using combat model simulations that do 
not represent UAS behavior and conditions that cause this variability may return misleading 
or incomplete results. Understanding when and how to model these conditions contributes to 
quality simulation and analysis. 


Current approaches include explicit scripting of behaviors and events. Combat models, includ¬ 
ing Combined Arms Analysis Tool for the 21st Century (COMBATXXI) [1], provide oppor¬ 
tunities for analysis. The ACQUIRE model is the most prevalent in U.S. Army simulations, 
allowing for the modeling of sensors used for search and targeting and acquisition (STA) [2]. 
Hierarchical Task Networks (HTNs) allow for automated planning based on changing environ¬ 
ments in the simulated world [3]. Ontologies can show the effects that detailed information may 
play on decision making when utilizing a UAS. This thesis proposes using dynamic behaviors 
to include hierarchal task networks, ontologies, and sensor models to represent the inherent 
complexity of a UAS in a simulation. We developed a proof of principle search, targeting and 
acquisition (STA) model for use with UAS within COMBATXXI leveraging existing STA re¬ 
search conducted at the Modeling, Virtual Environments and Simulation Institute (MOVES) at 
the Naval Postgraduate School. We showed that this methodology can result in analysis that 
gives insight into the effects the capabilities of a UAS offer regarding deployable force pro¬ 
tection (DEP). An ontology provides a means of representing pieces of information that, when 
combined with reason, was able to output relevant knowledge of the world and affect the out- 




come. This study used a seenario where understanding the ability to identify a target has a 
relationship to sueeessful exeeution. 


We demonstrated applieation of the new STA model in a taetieal convoy scenario in COM- 
BATXXI. The ability to model a UAS in a working environment is fundamental to a study 
eoneeming taetieal eonvoy operations. A design of experiments and post-exeeution analysis 
quantified the sensitivity of the measures of effeetiveness of sueeess to eonditions contributing 
to variability in UAS performance. Future work is given to identify possible studies that ean 
extend this researeh. 


XX 
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CHAPTER 1: 
INTRODUCTION 


1.1 BACKGROUND 

The United States Military is eonsidered the most powerful and effeetive fighting force when 
fighting a traditional red on blue, symmetrical war. Since the September 11, 2001, attacks, our 
enemies have been successful in mitigating our fighting strength through the use of improvised 
explosive devices (lEDs). The ability to counter such threats demand an adaptable and resilient 
force. Modeling and simulation (M&S) plays a vital role in developing scenarios that help 
leaders make decisions that can have lasting impacts on the battlefield. It is key that M&S 
provides decision makers with more fidelity and plausible results when studying the potential 
effects of systems used in theater. 

1.2 RESEARCH PROBLEM 

Current modeling techniques do not adequately provide the means to modify and measure the 
effects of changing the properties inherent to human/machine components and processes in an 
unmanned aircraft system (UAS). This research proposes an innovative way to represent the 
value of information and training in a constructive simulation, COMBATXXI (Combined Arms 
Analysis Tool for the 21st Century). Sensors in COMBATXXI do not allow for accurate mod¬ 
eling of lED detection when deploying UAS in a doctrinally correct manner. This may result in 
improper system deployment, overconfidence of capabilities, or unrealistic expectations caus¬ 
ing more harm than good to our Soldiers. This study will attempt to model decision making 
capabilities of a UAS in COMBATXXI, utilizing newly developed sensor modeling, dynamic 
planning methods, and ontology based reasoning. 

1.3 MOTIVATION 

The ability of a unit to effectively perform its mission is dependent on many factors including 
presence, posture, and safety. The U.S. Army relies on force protection at all times. Unmanned 
aerial vehicles (UAVs) are gaining in prevalence use since the War on Terrorism began after the 
tragic events of 9-11. As of 2010, Unmanned Aircraft Systems (UAS) are in use at echelons be¬ 
low battalion and below [5, p. 21]. Analyzing the effective use of a UAS can be performed using 
the U.S. Army’s high-resolution simulation COMBATXXI. This simulation models scenarios 
ranging from squad level building clearing operations to brigade-size amphibious assaults [1]. 


1 




COMBATXXI is extremely important for analysis of systems and ean be improved to represent 
the dynamies of a UAS’s information-gathering and its effeets. Understanding how information 
and training affeet deeision making may provide better insight on how we train, equip; and 
employ systems sueh as a UAS based on this new prototype. The study utilizes a new means of 
ereating behaviors in COMBATXXI by way of Hierarehieal Task Networks (HTNs). 

1.4 OBJECTIVES 

In order to develop a means to represent information and study the effeets of UAS operator 
skills when using this operation, we identify the following objeetives: 

• Utilize HTNs to assist in the formulation of behaviors more representative of eomplex 
systems in operation. 

• Deseribe a new method to represent knowledge in COMBATXXI through use of an on¬ 
tology and a new nontraditional sensor model. 

• Gather more knowledge on the effeets of information fidelity and varying eapabilities 
of sensors utilization of Unmanned Aireraft Systems in a deployable foree proteetion 
seenario. 

1.5 THESIS ORGANIZATION 

Chapter 1 lays out the plan to eompletion. The motivation for the thesis is given and provides 
the reader with guidanee in the direetion the study will take in order to answer the researeh 
questions. 

Chapter 2 provides a review of the UASs that the U.S. Army has in operation and other systems 
used elsewhere in the Department of Defense (DoD). The development of target aequisition 
models used in simulations is diseussed. Hierarehieal task networks are deseribed to provide 
the reader with an understanding of the value they provide to the developer when eompared to 
previous methods. A brief history of knowledge representation (KR) and its applieations are 
diseussed as well. 

Chapter 3 details the methodology used in the thesis from its ineeption to eompletion of the 
study. Novel ideas of using HTNs and an ontology approaeh are diseussed, providing the reader 
with a new method in KR implemented simulations. 

Chapter 4 deseribes the modeling of the Raven (unmanned aireraft of the Raven UAS) using 
a new STA model. This ehapter diseusses how an ontology of an lED eould allow an entity 
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to make a “realistic” determination of a threat based on the knowledge it is given through the 
sensor provided by the new STA model. 

Chapter 5 provides overall conclusion of the research and a discussion of possible further work. 
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CHAPTER 2: 
LITERATURE REVIEW 


2.1 U.S. MILITARY UNMANNED AIRCRAFT SYSTEMS IN OPERA¬ 
TION AND SIMULATION 

This chapter provides a review of the UAS in use by the U.S. Military. This includes systems 
that the U.S. Army has in operation and other systems only being used by other members 
of the U.S. Armed Forces. A short history of lEDs, their makeup, and means of detection 
will be examined along with the development of target acquisition models used in simulations. 
Hierarchical task networks are described in detail to provide the reader with an understanding 
of the value they provide to the developer when compared to previous methods. A brief history 
of knowledge representation and its applications are discussed as well. 

2.2 UNMANNED AIRCRAFT SYSTEM 

The term UAV (unmanned aerial vehicle) is the term most popularly used when discussing an 
unmanned aircraft that flies with a remotely located pilot. The UAV is part of a system-of- 
systems called an unmanned aircraft system. According to the U.S. Army [5, p8] “a UAS is 
comprised of an unmanned aircraft (UA), payload, human operator, control element, display, 
communication architecture, life cycle logistics, and the supported Soldier.” A UAS is capable 
of bringing the Warfighter value added service with systems such as electro-optical (EO) and 
infrared (IR) sensors to enhance intelligence, surveillance, and reconnaissance (ISR) capability. 
According to the U.S. Army 2010 UAS Roadmap, the five different groups of UASs being used 
are based on the following UA attributes: weight, altitude, and airspeed, see Eigure 2.1 [5, p. 
12]. These attributes were approved by the Joint Chiefs of Staff on November 25, 2008 [5, p. 
12 ]. 

2.2.1 Raven RQ-llB 

Ravens offer ISR capabilities for units at brigade (BDE) and lower echelons and currently sees 
high usage in oversea deployments. A report provided to Congress in 2012 reports that the 
U.S. Army, Navy and United States Special Operations Command (SOCOM) has 5,346 RQ-11 
vehicles in the inventory [6, p. 8]. The characteristics of this UAS are given in Eigure 2.2. This 
hand-launched UAV flies low and slow with cruising speeds between 17-44 knots (Eigure 2.3). 
It scans areas of interest (AOI) at an operating altitude of approximately 100-500 feet (30-152 
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UAS 

Category 

Max Gross 
Takeoff Weight 

Normal Operating Altitude (Ft) 

Airspeed 

Current Army UAS 
in Operation 

Group 1 

< 20 pounds 

< 1200 above ground level (AGL) 

<100 Knots 

RQ-11B Raven 

Group 2 

21-55 pounds 

< 3500 AGL 

<250 Knots 

No current system 

Group 3 

< 1320 pounds 

<18,000 mean sea level (MSL) 

RQ-7B Shadow 

Group 4 

> 1320 pounds 

Any Airspeed 

MQ-5B, MQ-IC 

Group 5 

> 18,000 MSL 

No current system 


Figure 2.1: Categories of Unmanned Aircraft Systems [5, p. 12]. The U.S. Army UAS catego¬ 
rization is from the “DoD 2009-2034 Unmanned Systems Integrated Roadmap” [5, p. 3]. As of 
2010 the Army does not have a Group 2 UAS. 


meters) above ground level (AGL). The sensor package allows the operator to gather data via 
EG or IR cameras using a continuous pan with a -I-IO- to -90-degree tilt. “The [Raven] can 
be operated manually or programmed for autonomous operation” [7]. The Raven would be the 
ideal asset for ISR capabilities for any squad-size mission (based on its specs) such as searching 
for lEDs along a route at known locations. 

2.2.2 Scan Eagle 

The Scan Eagle UAS is a Group 2 category UAS that performs missions for the U.S. Air Eorce 
and the U.S. Marine Corps (see Eigure 2.4). This UAV operates at altitudes up to 16,000 feet 
AGE (above ground level) and can stay aloft for more than twenty hours at speeds between 48- 
70 knots. The Scan Eagle payload consists of a high-resolution day/night camera and thermal 
imager. It catapults into operation with a launch and recovery system called Skyhook. This 
system requires four personnel (two operators, two maintainers) to run [10]. 

2.2.3 RQ-7B Shadow 

The RQ-7B Shadow UAS belongs to the UAS Group 3 category. This UAV can fly to altitudes 
of 15,000 feet AGE for nine hours of flight. Cruising speed is 90 knots with loitering capabilities 
at 65 knots. The unmanned aircraft can carry up to 80 pounds of sensors [11]. Eigure 2.5 shows 
a RQ-7 Shadow catapult from its hydraulic rail launcher. 

2.2.4 MQ-IC Gray Eagle 

The MQ-IC Gray Eagle (also known as “Warrior”) belongs in the Group 4 category. It is the up¬ 
grade of the MQ-1 Predator. The “M” and “Q” designation mean “multi-role” and “unmanned,” 
respectively. It has a wingspan of 56 feet and a length of 28 feet. This system can perform ISR 
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Standard Payk>ada 

Dual Forward and Side-Look EO Camera Noee, Electronic 
Pan-tllt-zoom writh Stabilization. Forward and Side-Look IR 
Camera Nose CB.S oz payioada) 

Ranga 

10 km 

Enduranca 

60-90 minutes (Rechargeable Batter^ 

Spaad 

32-81 km/h. 17-44 knots 

Oparating Altituda (Typ.) 

100-500 ft 00-152 m)/VGL. 14.000 ft MSL max launch attitude 

Wing Span 

4.5ft (1.4 m) 

Larrgth 

3.0 ft 0.9 irO 

Waight 

4.2 lbs a .9 kg) 

QC8 

Lightweight. Modular Components. Waterproof Softcase. 
Optional FalconVlew Moving Map and Mission Planning Laptop 
Interface. Digital Video Recorder and Frame (Capture 

Launch & Racovary Mathod 

Hand-Launched. Deep Stall Landing 


Figure 2.2: RQ-1 IB Specifications from Aerovironment [7]. The RQ-11 can fly “low and slow” 
traveling only 17 to 44 knots which equates to 30 to 60 mph. It is very lightweight 4.2 pounds, 
making it easy to employ by hand-launching. 


and communications relay missions, or be equipped with four Hellfire missiles. It has the abil¬ 
ity to fly to 29,000 feet and stay aloft for 25 hours with a maximum speed of 167 knots, see 
Figure 2.6 [13]. 

2.2.5 MQ-9 Reaper 

Introduced in 2001, the Reaper primarily performs the role of intelligence collection in support 
of strike, coordination, and reconnaissance missions [15]. It does not belong in the U.S. Army’s 
inventory but can support army missions. The Reaper is a Group 5 UAS with a 66-foot wingspan 
and is 36 feet, from nose to tail. Its maximum takeoff weight is 10,500 pounds. The hand- 
thrown Raven weighs a minuscule 4 pounds comparatively. The Reaper (Figure 2.7) flies at a 
maximum altitude of 50,000 feet and cruises at approximately 230 miles per hour (200 knots) 
at ranges up to 1,250 miles. It can fire Hellfire missiles or guided bombs, depending on mission 
requirements. 

2.3 IMPROVISED EXPLOSIVE DEVICES 

In this section, we provide a definition of an lED, its components, and means of detection in 
order to assist in making the lED ontology for the scenario to be used in the study. 
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Figure 2.3: Marine preparing to hand launch the 4.21b Raven UAV. From [8] The tripod in the 
back is part of Aerovironment’s Ground Control System (GCS), which “improves situational 
awareness of the ground, provides operators cue to potential threats, and enhances airborne 
intelligence, surveillance and reconnaissance (ISR)” [9]. 


2.3.1 History of lEDs 

The history of lEDs goes farther back than the “Global War on Terror.” They are a direct ambush 
weapon extremely effective in killing soft targets such as troops and/or lightly armored vehicles 
such as the High-Mobility Multipurpose Wheeled Vehicle (HMMWV). The DoD states that, 
“An lED is a device placed or fabricated in an improvised manner incorporating destructive, 
lethal, noxious, pyrotechnic, or incendiary chemicals and designed to destroy, incapacitate, 
harass, or distract. ...[the lED] may incorporate military stores, but is normally devised from 
nonmilitary components” [17, pII-14]. According to the Washington Post [18] as of August 
29, 2013, 2,503 out of 6,668 [fatalities] 37.5% were caused by lEDs in support of Operation 
Iraqi Ereedom and Operation Enduring Ereedom. If an lED explosion does not kill the entire 
crew in the vehicle, there is a very strong chance that survivors will likely suffer from tramatic 
brain injury (TBI), loss of limb, burn trauma, etc. The ability to detect and defeat (making lEDs 
inoperable once found) is paramount to current and future mission successes. 
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Figure 2.5: RQ-7B Shadow taking off. From [12] 
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Figure 2.6: U.S. Army Gray Eagle in flight. From [14] 



Figure 2.7: MQ-9 Reaper in flight with landing gear down. From [16] 

2.3.2 Makeup of lEDs 

In general, an lED [19, para 6-71] is made up of the following eomponents: 

1. Main eharge (explosive) 

2. Casing (materials around explosive) 
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3. Initiators (what triggers the explosion) 

(a) Command wired 

(b) Radio eontrolled 
(e) Vietim operated 
(d) Timed 

2.3.3 Detection of lEDs 

It is erueial that modeling deteetion of lEDs be performed to make it easier for U.S. Army 
leadership to understand the most beneficial ways to mitigate their effects when using UASs 
such as the Raven RQ-llB. The most dangerous way of detecting lEDs visually is from close 
proximity fewer than 5 meters. At distances of 100 meters or more detection is much safer, but 
more difficult. The enemy is continuously adapting their means of implementing lEDs, which 
make detection more difficult. Shepherd states in [20] that lEDs were first buried underground, 
then placed in and behind objects above ground, and then below ground again. Eater, they 
were found hidden in dead animals by the road, vehicles (vehicle-borne lEDs or VBIEDs), 
and humans (person-borne or PBIEDs). The enemy then began countering our mitigation by 
placing the lEDs underneath culverts or burying them underneath the roadway. One can see that 
winning the lED battle is a zero-sum game that costs millions of dollars, and more importantly, 
the lives and limbs of our soldiers. 

According to Shepherd [20] there are four methods to detecting lEDs: 

1. “Observing the [observation post] or triggerman.” 

2. “Identifying the explosives [lED indicators such as loose soil, wires, containers out of 
place, etc.] or where they are hidden.” 

3. “Gathering intelligence from the local population.” 

4. “Being attacked.” 

Shepherd [20] says that while leaders can use dismounts in staggered column formation or 
dismounted with vehicles in traveling overwatch, it is not always practical. Another means of 
detecting lEDs from a safe distance is through the use of unmanned aerial vehicles (UAVs). He 
sums up the use of aerial reconnaissance below when detecting lEDs: 


[UAVs] assigned to cavalry troops, as well as scouts in helicopters, can provide 
successful aerial reconnaissance. Aerial surveillance can move quicker and provide 
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Figure 2.8: Soldier looking through an image device in order to identify an object. From [21, p. 
1] This illustrates the point that the M&S community has to take real instruments and tools-like 
a camera-and create an abstraction (model) the light waves hitting the tank bouncing into the 
lens of the sensor (here a camera) and then travel back to observer’s eyes. 


advanced warning to reconnaissance elements on the ground. Scout elements on 
the ground can then move forward to confirm or deny information provided by air 
elements. [20] 


This concludes the discussion regarding the makeup and some detection methods for lEDs. 
Employing UASs to assist in detection of lEDs appears to be useful and promising. Since aerial 
reconnaissance is important during military operations, it may be necessary to develop methods 
of modeling this in a simulation. Next, we will look at how human sight has been modeled in 
the context of target acquisition modeling. This provides a better understanding of the dynamics 
and limitations of modeling human eyesight in current simulations. 

2.4 TARGET ACQUISITION MODELING 

In order to engage the enemy, one has to know the enemy’s whereabouts. Throughout history, 
commanders on land or at sea continue to deploy sentries/patrols to gain knowledge of the 
enemy’s location. Since WWII the use of electro-optic (EO) devices have become widespread, 
and are being utilized ubiquitously throughout the military. Vollermerhausen and Jacobs state: 
“The history of modeling EO imagers traces back almost 60 years to the pioneering work of 
Otto Schade... and [he] specifies that an EO image must be produced based on the capabilities 
and optical characteristics of the eye” [21, p. 9]. Schade had shown that it is possible to model 
the eye and created an analog model of the eye, which is “patterned after a television system” 
[22, p. 721]. Objective methods are used to test these characteristics and the “numerical values 
obtained by calculation...require correlation with the subjective impressions: graininess, tone 
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scale, and sharpness” [21, p. 9]. While his work is pioneering and a great foundation for 
modeling EO systems, it has been proven to be “eomplex and diffieult to adapt to ehanging 
eonditions” [21, p. 10]. Figure 2.8 illustrates a soldier looking through an image deviee to 
assist in his/her ability to assess whether an objeet is a threat or not. Not only is the human eye 
itself eomplieated, but adding to this eomplexity is trying to model photons hitting an objeet 
like a tank, bouneing into a deviee (UAV sensor), whieh in turn takes that image and makes a 
duplieate image. However, the M&S eommunity is asked to eome up with ways to best represent 
this real phenomena in simulations. 


2.4.1 Johnson Criteria 

Johnson Criteria assists analysts in understanding the eritieal dimensions neeessary for an ob¬ 
server to “see” a target. The United States Army Night Vision and Eleetronie Sensors Diree- 
torate (NVESD) state: “John Johnson, a Night Vision seientist, worked to develop methods of 
predieting target deteetion, orientation, reeognition, and identifieation. Johnson worked with 
volunteer observers to test eaeh individual’s ability to identify targets through image intensifier 
equipment under various eonditions” [23]. His models allow the ability to ereate predictive 
models of imagery systems. Johnson believed that alternating lines of a fixed width and spaeing 
enable one to eharaeterize the level of detail that ean be diseerned from an objeet. The thinner 
the line and eloser the spaeing, the more detail a person ean pereeive. He developed thresh¬ 
olds of line pairs to prediet a person’s ability to perform deteetion, orientation, reeognition, and 
identifieation [21, p. 7]. The Johnson Chart ean be found in Appendix A, whieh shows the 
minimum number of line pairs for the probability of 50% of observers to obtain deteetion, ori¬ 
entation, reeognition and resolution when looking at the target. Figure 2.9 illustrates the number 
of pixels needed for deteetion, reeognition and identifieation of a human being. It makes sense 
that the level of deteetion, reeognition, and identifieation is proportional to the number of pixels 
that eover the respeetive area of aequisition. Vollmerhausen and Jaeobs [21, p. 7] also state: 


The Johnson metrie uses limiting bar-ehart resolution as an indieator of sensor 
goodness for target aequisition purposes. Predietive aeeuraey of this metrie is best 
when eomparing “like” sensors and eonditions. The metrie is not eompatible with 
many features found in modem sensors. For example, it is not eompatible with sam¬ 
pled imagers. Further, the Johnson metrie fails to prediet the impaet of frequeney 
boost on range performanee. 
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The Johnson Criteria allows for the modeling of target aequisition predietability for different 
sensors eurrently in use by the U.S. Army. The metrie does have its limitations that may inhibit 
aecurate predietion of what humans will see when using imagery systems. The ACQUIRE 
model performs target aequisitions in COMBATXXI and requires the Johnson Criteria eritieal 
dimension for target deteetion. Sinee the Johnson Criteria are in need of an update to refleet the 
effects of STA when operating UASs, it may be beneficial to understand more about ACQUIRE 
and possibly construct a model without using the Johnson Criteria. 


Example: 

The Johnson Criteria assume that the critical dimension for a human being is 
0.75 meters. To get DRI, you need 1.5 pixels, 6 pixels and 12 pixels across 0.75 
meters In the object plane. That means: 

1.5 pixels/0.75m = 2 pixels per meter 
6 pixels/0.75 m = 8 pixels/meter 
12 pixels/0.75m = 16 pixels/meter 

Let us assume a man is 1.8m by 0.5m. So the man should be covered by: 



Detection = 

3.6 pixels by 1 pixel 
You can see something 
is there. 


Recognition = Identification = 

14.4 pixels by 4 pixels 28.8 pixels by 8 pixels 

You can see that a person You can see that the 

Is there. person is holding a rifle. 


Images onfyintented to represent the concept 


Eigure 2.9: Illustration of number of pixels required for detection, recognition, and identifica¬ 
tion of a human being. Erom [24, p. 3] 


2.4.2 ACQUIRE 

The most prevalent target acquisition model the U.S. Army operates in combat simulations is 
the ACQUIRE model. The ACQUIRE model was formulated in 1990 and is a continuation of 
the Johnson Criteria [25, pp. 1-2] According to Darken [26, p. 263] “ACQUIRE computes the 
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detection probability as a function of the brightness...of the target, the brightness of the back¬ 
ground of the target, and the subjective size of the target, in terms of its ‘number of resolvable 
cycles.’” The ACQUIRE model uses physical sensor characteristic data and human percep¬ 
tual data along with environmental factors to compute a probability of detection for a specific 
observer-target configuration. In combat models such as COMBATXXI, this data coupled with 
a stochastic process allows for determining an actual outcome of a simulated observation. For 
example, ACQUIRE computes the probability that one will see a target given a target’s range 
and the entity’s sensor as .78. COMBATXXI then randomly draws a (uniform) number from 
0-1 (where all values between 0 and 1 have an equal chance of being selected). If the number 
drawn is equal or less than .78 the simulation says that target is “seen” otherwise, the target is 
not seen even though there is clear line of sight between the sensor and the target. 

ETC Baez [27] identifies some major drawbacks to the ACQUIRE model: 

• “Current [model has] not been calibrated or developed for close-in targets within 200 
meters” [27, p. 5]. 

• “Simulated soldiers can scan large fields of regard (FOR) quicker and make significantly 
quicker detections and identifications than a real soldier” [27, p. 5]. 

• Unvalidated workarounds have been made for limitations such as moving targets, multiple 
targets, clutter effects, color effects. 

• Eack of updated visual perception experiments for targets not in database (i.e., compo¬ 
nents of lEDs). 

These four items listed above hinder the ability to accurately predict the detection of targets by 
a UAS modeled in this study. The UAS that will be modeled in COMBATXXI for this study 
is the Raven RQ-lIB. The Raven generally operates between altitudes of 30-152 meters [7]. 
When operating the Raven soldiers scan the hand-held screen and probably do not always detect 
(within a reasonable amount of time) objects such as a person holding a cell phone, misplaced 
box along the road, wires coming out of the ground. To compound the problem, there are no 
known human experiments that have been run to accurately model the detection of items using 
a sensor such as this UAS. 


2.5 COMBATXXI 

The Combined Arms Analysis Tool for the 21st Century (COMBATXXI) is a detailed event- 
driven simulation developed by U.S. Army Training and Doctrine Command White Sands Mis- 
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sile Range (TRAC-WSMR) and Marine Corps Combat Development Command (MCCDC). 
The COMBATXXI User’s Guide deseribes this simulation as “A Joint, high-resolution, elosed- 
form, stoehastie, discrete event, entity level structure analytical combat simulation” [1, p. 14]. 
Some of the major model functions include “Ground Combat (Light and Heavy Forces), Future 
forces. Fixed-wing and rotary wing” [1, p. 14]. One of the goals of COMBATXXI is to provide 
“a simulation that can represent information flow in a way that allows the analysis of its impact 
on operational effectiveness” [1, p. 14]. 

Behaviors of entities in COMBATXXI can be specified by model users using [1, p. 317]: 

• Orders 

• BSL (Behavior Specification Language, the native scripting language in COMBATXXI). 

• Python scripts 

Orders are the easiest for the programmer to use and are grouped into compound orders to 
perform more complex actions. BSL provides more complex behavior structures and a way 
to connect to complex internally defined behaviors. However, BSL restricts access to certain 
objects and data outside the model, which limits its use of making complex, dynamic behaviors. 
Python allows for the most flexible method of developing dynamic, “realistic” behaviors in 
COMBATXXI. To the non-programmer this may be seem a little intimidating. Figure 2.10 
relates the types of behavior being programmed to the difficulty of implementation. The next 
section provides information on how this study will utilize dynamic planning methods and tools 
to assist in creating these dynamic behaviors. 



Figure 2.10: Relationship of behavior (static, dynamic) vs usability (easy, difficult) when con¬ 
sidering different programming methods in COMBATXXI. From [1, p. 317] 
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HTN Tasks and Shapes 

Tasks 

Shape 

Primitive Task 

# 

Compound Tasks 

■ w 

Goal Tasks 

• 

Constraint Node 



Table 2.1: HTN Task and Nodes. From [30] 


2.6 HIERARCHICAL TASK NETWORKS 

The father of modern-day hierarchical task networks is Earl Sacerdoti, who describes HTNs as 
“procedural nets” [28]. HTNs are a means of planning actions in a program via the traversal of 
a series of networks in order to reach a goal. Sohrabi, Baier, Mcllraith [29] state: “the planner is 
provided with a set of tasks to be performed, possibly together with constraints on those tasks. 
A plan is then formulated by repeatedly decomposing tasks into smaller and smaller subtasks 
until primitive, executable tasks are reached.” Traditional HTNs consider what is to be the 
desired state of world, finds the plan (based solely on the current state of the world) which then 
is executed to reach the goal state (the desired state of the world). 


2.6.1 Basic Terminology of HTNs 

In order to fully appreciate the potential of HTNs, some basic terminology must be defined. 
Primitive tasks are tasks that cannot be broken down any further. A compound task consists of 
a collection of tasks that may be primitive or complex. Goals or goal tasks represent the final 
world state the HTN is trying to achieve. Constraints are the conditions that must be true in 
order to execute a specific branch of the HTN. See Table 2.1 for the graphics that correspond to 
an HTN task and/or nodes. 

HTN trees are read from left to right and then top to bottom. Traversal of the HTN is complete 
once the goal node is reached. If the goal node is not reached, then the HTN might not finish 
and thus the goal state is never reached. Proper HTN fabrication allows for goal nodes to 
always be reached [3]. In the next section, an example of a static HTN in operation provides an 
opportunity to understand traditional automated planning. 
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2.6.2 Example of Static HTN Planning 

A HTN creates a plan to implement the behavior of someone going to the store (see Figure 2.11). 
The plan is based on the current state of the world and is valid as long as the state of the world 
does not change; remains static. The traversal of this tree illustrates the methodology of HTNs. 
First, the “Go to Store” compound task begins execution. Next it moves to the first and only 
constraint “Find Keys.” If “Find Keys” has value of “True” then the tree traverses to the first 
primitive (non-compound) task “Get in Car.” After this task the program automatically executes 
“Drive to Store.” Once “Arrive at Store” executes, the goal has been reached and the HTN 
terminates. Going back to the “Find Keys” constraint node, if one does not have keys (value of 
“Find Keys” constraint has value of “False”) then the “Walk to Store” primitive task is reached 
and then “Arrive at Store” performs and the HTN terminates. Using HTNs this way is great 
if and only if the conditions (known state of the world) have not changed since the plan was 
formulated and execution was started. But cars do break down and/or run out of gas. Road 
construction causes detours resulting in alternating course (changing plan) in order to ensure 
that the goal “Go to Store” is met. To address these types of problems, modifications need to be 
made to the HTN methodology. In the next subsection the use of dynamic planning is discussed. 


2.6.3 Example of Dynamic HTN Planning 

If the state of the world changes after a developed plan starts execution the entity may never 
reach its goal. To account for a possible change, the programmer may add an interrupt goal to 
force the HTN planner to reassess and replan actions to ensure a feasible plan is made. Interrupt 
nodes for this demonstration are labeled red. Balogh et al. state that interrupt nodes serve two 
purposes: “represent tasks that takes some time to complete and are likely places where the 
plan become invalid and allow for the Tazy generation’ of the plan only part of the plan needs 
to be generated” [3, p. 4]. In addition to the interrupt node, the idea of a replan event needs to 
be introduced. A “replan event” will cause the tree to “suspend execution of the current plan 
and reevaluate the HTN being used to determine how the plan should be changed based on the 
current state of the world” [30, slide 13]. 

Looking at Figure 2.12, it displays the “Go to Store” task with the addition of interrupt goals. 
For this example the idea is that one is at home (at the start of execution) and along the way to 
the store, a problem will arise causing the planner to account for this unexpected event, which 
would normally cause the plan to be void and the goal never met. The replan event indicates 
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START TREE (L to R) 

• ‘Go To Store’task starts 
execution 

• ‘Go To Store'(compoundtask) 
passes to the first task-‘Find 
Keys'(constraint) 


PASSES CONSTRAINT 

• ‘Getin Car’(primitivetask)executesand 
passes to‘Drive To Store'. 

• ‘Drive To Store'(primrtive task)executes 
and passes to 'Arrive At Store'. 

• ‘Arrive At Store'(goal task) completes the 
plan 


Go to 

Find 

T 


Get 

Drive 

Store 

^ Keys 



Car 

store 


FAILS CONSTRAINT 

• ‘Walk To Store’(primitivetask) 
executes and passes to ‘Arrive At 
Store' 

• ‘Arrive At Store'(goal task) 
completesthe plan 




11-u Are 2012 


Figure 2.11: Planning to go to store without aeeounting for ehanges in the environment. From 
[30, slide 8] 


that a state is reached where a change in the state of the world could occur and the whole plan 
will re-evaluate. When an interrupt node is hit, the execution of the tree halts, pending a replan 
event causing the tree being reevaluated. The replan event for this tree is “Stopped Moving.” 
First the “Go to Store” compound task executes and reaches the “At Store?,” which has a value 
of “False.” Next the “At Home?” (interrupt node) has value “True” and tree planner moves to 
constraint node “Find Keys.” Since that is true “Get in Car” task is planned, which then triggers 
the interrupt node “Drive to Store,” causing the planner to stop executing. Since the replan event 
“Stop Moving” was triggered after “Drive to Store” event executed, the tree re-executes at the 
root node “Go to Store.” The tree looks at constraint node “At Store?,” whose value is “False,” 
then moves to “At Home?” constraint node whose value is also “False” then plans an “Walk to 
Store” node. The “Walk to Store” node triggers the “Stop Moving” event causing the tree to 
be executed again. The task “Go to Store” executes and moves to constraint node “At Store?” 
being “True” causing the “Arrive at Store” goal node to execute allowing tree to be completed 
and finished. The interrupt node allows the tree to stop executing to allow for replan triggers to 


19 
























cause the tree to form a new plan in order to reaeh a goal. 
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entity would end up walking to the 
store. 


1 

-r Find 


Get 

/ Drive 

' Home 

Keys 


► in 

to 

■7 

X 

f\ 


Car 

Vy^Store^ 


'v^tore^ 


“STOP MOVING” EVENT TRIGGERED 

• ‘Go to Store’task starts execution ‘Goto Store’task starts execution 

• 'At Store?’ is true, pass to 'Arrive At Store' 

•‘Arrive At Store' (goal no<}e) indicates the world is at the desired state 
•HTN is finished and the plan is removed. 
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Figure 2.12: Going to store with an interrupt node. From [30, slide 19] 


2.7 KNOWLEDGE REPRESENTATION 

Information ean be pieees of faet and fietion that deseribe the world around us. Knowledge is 
the eollection of information that allows for intelligible aetion to take plaee. It is imperative 
that one knows how to apply knowledge and relate it to ideas that ean aeeurately refieet the 
message one is trying to eonvey. Braehman and Levesque say knowledge representation is “the 
field of study eoneerned with using formal symbols to represent a eollection of propositions 
believed by some putative agent” [31, p. 4]. Davis, Shrobe, and Szolovits see knowledge 
representation (KR) as “a surrogate, a substitute for the thing itself, that is used to enable an 
entity to determine consequences by thinking rather than aeting that is, by reasoning about the 
world than [5zc] taking aetion on it” [32, p. 17]. They explain one of the most interesting 
aspeets of reasoning is that one must deeide what the surrogate represents and what level of 
fidelity is the surrogate given when deseribing the entity [32, p. 18]. Their example eonsists of 
an entity planning on assembling a bieyele. There are different parts of the bieyele the person 
would have to think about (internally) that exist (externally) [32, p. 18]. Ways of representing 
knowledge via eomputers have been around for over fifty years. Some means of KR have 
ineluded “neural networks, theorem proving and expert systems” [33]. In order to eommunieate 
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an idea effectively, one needs to be able to speak in a manner that both parties can understand 
(a common language). There are languages (old and new) that have been adopted and created 
to help present the understanding of the world. A unique problem with Artificial Intelligence 
(AI) is that a program needs to have precise understanding of what the digit “2” is versus the 
string “too.” We, as humans, must know how and when to use “2” and “too” when talking to 
one another. For example, concepts such as aircraft, flying, and travel can be closely related 
or very far apart. It all depends on the idea that you are trying to represent. If one is trying 
to plan a trip to Disneyland the first thought is the modes of “travel.” Travel could happen by 
driving, sailing, swimming (if you are a good swimmer) or flying. By flying, concepts such as 
“soaring,” “being lighter than air,” “flapping of wings” may come to mind. However, since the 
context is in the realm of transporting a person from their home town to Disneyland, it is most 
likely that “flapping of wings” is not the true method of flying in this scenario. A depiction of 
being enclosed in a fuselage resembling something like a Boeing 737 or Airbus 350 and soaring 
through the clouds may be more accurate. The aircraft engineer might visualize movement of 
air molecules over the wings creating lift opposing the downward force of gravity. There are 
infinite ways to represent knowledge, unlike many problems that have a constrained solution 
space. Below are some areas that have been used to formally represent knowledge. 

2.7.1 Propositional Calculus 

Propositional calculus (aka propositional logic) is said to have been first created by the philoso¬ 
pher Aristotle [34]. In general, it is made up of symbols, truth symbols, and connectives. 
Propostional logic “is the branch of logic that studies ways of joining and/or modifying en¬ 
tire propositions, statements or sentences to form more complicated propositions, statements 
or sentences” [34]. These propositional sentences declare if the proposition is true or false 
[34]. Well-formed formulas (WFFs) are legal sentences in PL. Table 2.2 shows the symbols 
and well-formed fumulas. Propositional logic is concerned with the assigning of truth-values 
to a proposition (true or false). A PL sentence cannot be both true and false. The “Internet 
Encyclopedia of Philosophy” provides a very thorough review of Propositional logic [34]. 

2.7.2 Predicate Calculus 

Predicate calculus allows one to tie relationships together and make clearer connections to ob¬ 
jects, persons, ideas,...etc. Sentences are formed in predicate calculus just like they are in 
propositional calculus using the same connectives as found in Table 2.2. In propositional logic 
the atoms “P” and “Q” represent a proposition that only has meaning to itself and itself alone. 
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Symbols of Propositional Calculus 

Propositional Symbols 

P 

Q 

“The sun is shining.” 

“Today is Friday.” 

Truth Symbols 

true 

false 

“True” 

"False" 


—1 

negation, “not” 


A 

conjunction, “and” 

Connectives 

V 

disjunction, “or” 


-)■ 

implication, “if...then...” 


= 

equivalence, “equivalent to” 


P,Q,R 

Propositions 

Well-Formed Formulas (WFFs) 

^P 

P^ Q 

"not P" 

"P implies Q" 


P A Q = R 

"P and Q is equivalent to R" 


Table 2.2: Propositional Calculus Symbols. 


However, with predicate calculus, values can be assigned to the propositions individually, which 
allows the ability to make new inferences by explicitly referring to the values assigned to the 
symbols. If “X” is a variable representing hours of the day and sentence “weather(X, sunny)” 
is true then literally one is expressing “the weather is sunny all the hours of the day.” Two new 
symbols are introduced in predicate calculus: the universal quantifier, V , and existential quan¬ 
tifier, 3 . The universal quantifier states that a sentence is true for all values of the variable. The 
existential quantifier states that there exists at least one value of the variable that make a sen¬ 
tence true. Luger states, “A major challenge for AI programmers is to find a scheme for using 
these predicates that optimizes the expressiveness and efficiency of the resulting representation” 
[35, p. 60]. Table 2.3 shows the power of representing “knowledge” using predicate calculus. 
Predicate calculus allows for a formalized fabrication of information enabling the structuring of 
knowledge bases, which will be shown later in the thesis. 

2.7.3 Semantic Networks 

A semantic network can be used to represent knowledge by using meaningful relationships with 
nodes and arcs. According to associationists, “when humans perceive an object, that perception 
is first mapped into a concept. This concept is part of our entire knowledge of the world and is 
connected through appropriate relationships to other concepts” [35, p. 229]. AI pioneers Collins 
and Quillian fabricate a semantic network based on human information and storage times. It 
is said that by using inheritance, humans are able to decrease the size of needed knowledge 
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Predicate Calculus and the English Fanguage 

If it does not rain on Monday, 

Tom will go to the mountains. 

-iweather(rain, monday)—)-go(tom, mountains) 

Emma is a Doberman pinscher 
and a good dog. 

gooddog(emma) Aisa(emma, doberman) 

All basketball players are tall. 

V X (basketball_player(X) —>tall(X)) 

Some people like anchovies. 

3X (person(X, anchovies)) 

If wishes were horses, beggars would ride. 

equal(wishes, horses)—)-ride(beggars) 

Nobody likes taxes. 

-i3X likes(X, taxes) 


Table 2.3: English sentences being used in predicate calculus. After [35, p. 60] 

base by this form of abstraction. Figure 2.13 shows a Collins and Quillan hierarchy of two 
distinct type of birds, characteristics of birds, and how they both relate to animals representing 
the idea of inheritance. A node could represent concepts such as objects, ideas, or situations. 
The arc represents the relationship between two objects, ideas or situations. Figure 2.13 shows 
a representation of how human information could be stored in memory of a computer via a 
semantic network. This is why it is important to understand how a semantic network can be 
built to better understand beings, ideas, and the relationships they share. 

2.7.4 Ontologies 

An ontology is a way of creating our knowledge base (KB) of the world and having the agent 
of interest act upon the knowledge it knows of the world and make new inferences. We can 
use predicate calculus to help create the “facts’” of our known world. Merriam-Webster defines 
ontology as “a branch of metaphysics concerned with the nature and relations of being” [37]. 
Brachman and Fevesque state “[ontology represents] the kinds of objects that will be important 
to the agent and the properties those objects will be thought to have, and the relationships 
among them” [31, p. 32]. There are software programs that can assist in developing simple 
to rather complex ontologies that would be otherwise impossible for a human to store in his 
or her brain. The Web Ontology Fanguage (OWE) is a high-level knowledge-based language 
used to construct knowledge base for many domains. It allows for machines (computers) to 
automatically process information based on the predicate’s expressiveness. Childers discusses 
the benefits of using ontologies “[because ontologies]...allows programs to understand, process, 
and infer new information from coherent data” [38, p. V]. An ontology should assist in the 
creation of a knowledge base enabling a better understanding of the importance of acquiring 
accurate and useful information such from sensors in a UAS. 
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Figure 2.13: Semantic Network from Collins and Quillian modeling how information would be 
stored in a computer. This is a modified remake of their illustration. From [36, p. 241] 

2.8 SUMMARY 

The DoD has use for many types of UASs, of which one is reconnaissance. There are methods 
to model the sensors and sensing systems on these aircraft, however, they have drawbacks. In 
modeling, there are many ways to represent knowledge and decision making. 
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CHAPTER 3: 
METHODOLOGY 


3.1 INTRODUCTION 

The methodology begins with developing a scenario that implements the Raven UAS in an 
typical Southwest Asian (SWA) environment. HTNs form the basis for planning and creating 
behaviors of the entities in the scenario. The creation of design of experiments and an ontology 
assist in measuring the effects of UAV operator skill and decision making. 

3.2 SCENARIO 

In order to understand the capabilities, limitations, pros and cons of an UAS, it is imperative that 
we consider the context of its usage. For this thesis, the scenario takes place in Southwest Asia. 
The 5-Ws (who, what, when, where and why) give the reader the understanding of what kind 
of mission will take place. Below is a brief description of the scenario [39] to be modeled in 
COMBATXXI. It represents a scenario that a small unit living on a combat outpost (COP) may 
have to perform while conducting operations with a host nation’s army in SWA (see Appendix 
B). 

• Who: Squad of U.S. Forces from COP Ramrod consisting of 7 vehicles and 1 RQ-llB 
RAVEN UAS. 

• What: Conduct Resupply Run to Outpost X-Ray 

• When: 0800 Hours Local Time 

• Where: On an unimproved route consisting mainly of dirt and some gravel. 

• Why: To resupply a joint American/Host Nation Outpost consisting of approximately 30 
personnel. 

Along the route there are areas known to have a higher than normal likelihood of containing an 
lED. There are four named areas of interest (NAIs) that have an equal chance of having an lED. 
For this study the real lED can be found in NAI # 2. The Raven UAS provides the added ability 
for the convoy commander to search the area at a safer distance than without a Raven. In the 
study it is assumed that a convoy will not see signs of a possible lED until they are within close 
proximity of one (approximately 50 meters). The mission can be seen in Eigure 3.1 with NAIs 
and the convoy’s start and end points labeled. 
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Figure 3.1: Mission Overlay in COMBATXXI. 

When the convoy passes each phase line (PL) at the start of each NAI, they will stop and deploy 
the Raven. It will search each NAI by flying along a pre-determined path in search of an lED, 
see Figure 3.2. An object representing the lED will only detonate with an assigned standard 
uniform probability of .8 given that a convoy entity enters lED’s sensor range of 10 meters. 
If an object is outside of the 10 meter range, the LED will never activate. The Raven UAS 
will defeat the lED if 1) the UAV detects the object that “could” be an LED (based on new 
UAV sensor model) and 2) the operator believes that the object detected is an lED and takes 
appropriate action by calling the unexploded ordnance clearing team (EOD). Calling EOD will 
always result in a 60-minute time penalty and LED being destroyed. If the convoy is hit by an 
lED, then mission is over. Success is the ability for convoy to safely arrive without taking any 
casualties. 
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Figure 3.2: Screen shot of NAI 1. 


Next, the research will look in to developing behaviors of our entities in the COMBATXXI 
scenario. 

3.3 FORMULATION OF BEHAVIORS 

The study uses HTNs to define behaviors for the entities modeled in the research. A tool called 
"Behavior Studio," developed by the MOVES Institute, provided for formation of behaviors. 
HTNs promise to make coding behaviors less time intensive, more efficient, etc., and in doing so 
allow for quicker formation of behaviors to be analyzed. An HTN tree is one separate entity that 
has a root node and at least one goal node. Each tree is organized with an initialization branch 
and execution branches. The execution branches consist of events and mode IE vents. The 
events generally consist of events that are organic to the planner, whereas modelEvents plans 
for the execution of events directed by COMBATXXI exclusively. The list of trees for this study 
are as follows, with a broad description of the behavior to be modeled. 

• ConvoyMoveInFormation: Behavior of moving convoy along the route. 

• OperatelED; Behavior enabling detonation of lED when appropriate. 

• OperateUAS: Behavior for operation of the UAV and convoy. 

• UAVSensor: Behavior of the Raven UAV sensors. 

3.3.1 Moving the Convoy HTN 

The behavior tree labeled ConvoyMoveInFormation is responsible for ensuring the con¬ 
voy reaches its final destination (Outpost X-Ray), see Eigure 3.3. When the tree executes it 
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Figure 3.3: ConvoyMoveInFormationTree. This tree will form a plan to get the convoy 
from the COP Ramrod to OP X-Ray. 

first “initializes” using the initinfo and runs to the first condition isCommander, which 
tells that there are the NAI phaselines to pay attention to and schedules a “Move Out” event. 
Then several replan triggers are added for the tree listen to via addReplanTriggers node. 
The doNothing node tells the tree to end planning if someone other than the commander is 
assigned this tree. Once the initinfo branch completes, the execution is interrupted and is 
waiting for a replan event. 

When a replan event occurs different nodes may execute. The moveOut node orders the convoy 


28 






to move out. The pickedUpUAS interrupt node informs the eonvoy eommander if the UAS 
(Raven) is physieally baek with eonvoy. If the UAS has not seen any artifaets that eould be 
dangerous (sueh as potential lEDs) it sehedules an “ResumeMovingAtSpeed” event. If the eon- 
dition IsResumeMovingAtSpeed is true the plan passes to the resumeMoving interrupt 
node that has the eonvoy resume normal eonvoy speed. 

Next, moving on to modelEvents node, if eonditions are true in nodes isAtControlMeasure 
and isAtPhaseLine then the eonvoy will eome to a “halt” (stopAndWait). Raven dis- 
patehes in seareh of lEDs, respeetively. The dispatchUAS interrupt node will assign the 
OperateUAS tree to the the UAV entity to exeeute and seareh the eurrent NAI. 

If the isDamageOccured node is “true,” then the eonvoy has been hit by an lED, meaning 
the mission is over and the plan terminates appropriately. And finally, if the eonvoy has reaehed 
its final destination, the doneWithMission node is exeeuted and the tree terminates. The 
eomplete ConvoyMoveInFormation tree ean be seen in Appendix C. 

3.3.2 Operating the lED HTN 

The HTN tree labled OperatelED forms the behavior of the improvised explosive deviee. 

Eigure 3.4 shows the tree in its entirety. Eirst the tree jumps into the initinfo node and 
eheeks to see if the objeet is a real lED (isReallED) by eheeking to see if probability of deto¬ 
nation is greater than 0. If objeet is not an lED the tree moves to goal node set IsNot lEDInf o 
and finishes. However, if isReallED eondition is “true” the tree moves to the startObservation 
node, aetivating the lED if eonvoy entity is within the aetivation (sensor) range of lED. Next 
the addReplanTriggers exeeutes and ensures OperatelED tree is replanned if entities 
enter lED’s area of interest (AOI), the simulation publishes a “GoalTraeker_Detonate Now” 
event. Now moving along into the events braneh, the lED detonates as long as “doGoal- 
Traeker_DetonateNow” is true. The lED will detonate with a probability (0.8 for the study) 
passed in as a parameter and is ALWAYS eatastrophie (no survivors). The modelEvents 
node sehedules a replan trigger ealled “GoalTraeker_DetonateNow” when the seeond vehiele 
enters the lED’s killzone. The eomplete OperatelED node ean be seen in Appendix D. 

3.3.3 Operating the UAS HTN 

The HTN tree OperateUAS forms the behavior of operating the UAS, see Eigure 3.5. Like 
earlier HTNs, the tree first initializes and adds replan triggers that will eause the tree to re¬ 
plan when the UAS is finished searehing or seanning the NAI. Next, the tree plans routes for 
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OperatelED 
? Initinfo 

? IsReallED 

startObservation 
addReplanlrlggers 
setlsNotlEDInfo 
f events 

t IsGoalTrackerEvent 

? isDetonateNow 

detonate 

f mu modelEvents 
f isEnteredAOl 

entityEnteredAOl 


Figure 3.4: OperatelEDTree. Picture of OperatelED HTN. 


OperateUAS 
f initinfo 

addReplanlrlggers 
createUASRoutes 
f events 

t isGoailrackerEvent 

? isCompletedFOVScan 

checKSensor 
f modelEvents 

? isHaveLanded 

UASLanded 

f isHaveEmbarked 

doneWittiMission 


Figure 3.5: OperateUASTree. Picture of OperateUAS HTN. 


the UAV to operate, see interrupt node createUASRoutes. Moving to events node, the 
branch is responsible for checking the sensor for objects found once it finishes scanning. The 
isCompletedFOVScan checks if UAV scanning its field of regard (FOR). If isCompletedFOVScan 
has value of “true” then the interrupt node checkSensor executes. In this node, if the UAV 
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Figure 3.6: UAVSensor Tree. 

entity has not returned to the eonvoy or is greater than 100 meters out from vehiele it dis¬ 
embarked, the tree will push the UAV sensor tree to UAVSensor tree where the UAV entity 
eontinues its seareh of FOR with neeessary parameters. 

When the tree traverses down to the modelEvent s onee the eonstraint node isHaveLanded 
is true, the UASLanded node exeeutes-meaning that the Raven UAV has landed. Lastly, onee 
the UAV embarks the eonvoy (it just eompleted its mission), then the goal node doneWithMission 
exeeutes and the human operator determines if this is either an lED or not an lED. A more de¬ 
tailed depletion of the tree ean be given in Appendix E. 

3.3.4 UAV Sensing HTN 

The UAVSensor HTN is responsible for modeling the sensor of our Raven UAV (see Eig- 
ure 3.6). The goal here is to model a user observing through a single field of view. Eirst the 
tree initializes and the init search node eomputes a sean time for the EOR (field of regard). 
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which is simply what the person is foeusing on the screen. The field of view (FOV) is the en¬ 
tire sereen that the observer eannot see due to the eyes abilities to only focus on a few degrees 
at a time. Moving down into the events braneh if the isGoalTrackerEvent node and 
isStartFOVScan node are true the interrupt node scanFOV exeeutes. In this node, the 
UAV searches for objeets on the ground using an EO sensor. It has the probability of detecting 
objects in its path based on the distance. Looking at the isFOVScanDone node is true, it 
passes to the goal node scanDone. This node finishes the tree and the “observations” will be 
looked at in the OperateUAS node (mentioned earlier) for determination if it is or is not an 
lED. A more detailed depletion of the tree in its entirety ean be found in Appendix E. 

3.4 UAV NOTIONAL SENSOR MODEL 

To aehieve the representation of a UAS modeling the effeets of operator skill, we need a sensor. 
The sensor must be able to report to the OperateUAS HTN (representing human behavior) all 
possible lEDs. Currently the sensor in COMBATXXI is overly sensitive and cannot determine 
if an objeet found is an lED unless it is hard-seripted into that objeet as a real lED. Therefore the 
study uses a simple notational sensor developed by Imre Balogh (see Appendix E). The UAV 
sensor model ean deteet objeets in COMBATXXI using some simple geometry and probability. 
Looking at Eigure 3.7 one ean see how the UAV deteets an objeet. Probability of detection is 
based on the value of r. Eor this model the limit to detect an object is 220 meters. If the range 
of an objeet is 110 meters then the observer has a .50 chance of deteeting objeet given that it is 
in the field of view of the sensor. Next, the study will look at the idea of creating a knowledge 
base (an ontology) that would assist the UAS operator in making deeisions based on clues sueh 
as “disturbed earth,” and “loose wires,” instead of finding an object and flipping a coin to say 
that it is or is not an lED (as explained for COMBATXXI). 

3.5 ONTOLOGY OE lED 

Ontologies are a useful way of expressing knowledge of the world. They help to formalize 
an understanding of what objeets will be represented and the relationships the objeets share 
together [31, p. 32]. The agent in this study is the UAS and its ability to diseern threat-type 
based on information received. 

3.5.1 Developing an Ontology 

This study seeks to develop a eonstraint that will allow our HTN to eategorize the objects it 
observes. This categorization defines a state based on indicators in the ontology. This pereeived 
state determines the seleetion of behaviors to follow in the HTN. 
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Figure 3.7: A depiction of the UAV Sensor Model used in this study. Courtesy from Imre 
Balogh [40]. 


This research uses the free, open-source program Protege 4.3 to create a knowledge base (KB) 
of the world of lEDs [4]. According to the Protge website, “Protege implements a rich set 
of knowledge-modeling structures and actions that support the creation, visualization, and ma¬ 
nipulation of ontologies in various representation formats”[4]. There are two methods that 
ontologies can be formed: (1.) Protege-Frames editor “frame-based, in accordance with the 
Open Knowledge Base Connectivity protocol (OKBC)” and (2.) Protege-Owl editor, which 
“enables users to build ontologies for the Semantic Web, in particular the W3C’s [(World Wide 
Web Consortium)] Web Ontology Language OWL” [4]. The W3C website states “The OWL 
can be used to explicitly represent the meaning of terms in vocabularies and the relationships 
between those terms” [41]. The study uses Protege-OWL editor (version 4.3, build 304) to cre¬ 
ate the ILD ontology. According to the Protege-OWL website, “OWL ontology may include 
descriptions of classes, properties and their instances. Given such an ontology, the OWL formal 
semantics specifies how to derive its logical consequences, i.e., facts not literally present in the 
ontology, but entailed by the semantics” [4]. These logical consequences are derived by using 
the reasoner. A reasoner is “a piece of software able to infer logical consequences from a set 
of asserted facts or axioms” [42]. This study uses the Lact-|--|- (fact plus plus) description logic 
(DL) reasoner. 
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3.5.2 Representing Information in an OWL Ontology 

There are three main eoneepts when building an OWL ontology: elasses, properties, and in- 
stanees. The sereen you see in Figure 3.8 shows the Protege 4.3 user interfaee; the tabs used to 
create the ontology along with the reasoner are circled. 



Figure 3.8: Screen picture of Protege 4.3 program with the main tabs used circled. The Classes 
tab is shown. 



Figure 3.9: Thing class shown with its subclasses. lED class is a subclass of class Thing. 


3.5.3 Defining Classes in lEDOntology 

For this research, a preliminary ontology of lEDs was developed. The ontology is not fully 
defined, but provides a limited set of class and property definitions to demonstrate use of the 
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ontology and automated reasoning to make inferences about detected lEDs based on informa¬ 
tion reported from human or automated observers in the battlespace. 

In the Ontology (see Appendix G), the main classes can be seen in Figure 3.9.The lED class is 
shown (circled) with the other classes in the lED ontology. The main class is always the Thing 
class [43, p. 15]. The ultimate goal is to classify something as being some type of “lED,” but 
in order to have a better understanding of the makeup of an lED, it is imperative that its sibling 
classes be defined first. The first sibling of class lED is the DeliveryMethod, which defines 

Fie Edit Vew Reasoner Tools Refactor Window Help 

I |<S>led ---.r -v- led " ~ : | 

' Individuals ^operty matrw Individuals matrix 1j OWLViz || [)LQiiefy OntoGraf [' OntologyDifferences [^ ^AR^Query | 



Reasoner active 0 Show Inferences 

Eigure 3.10: DeliveryMethod class shown with its disjoint sibling classes. 

delivery method of an LED to its intended target (via human, package, or vehicle). The classes 
Human, Package, and Vehicle are subclasses of the parent class DeliveryMethod and 
are siblings to each other. This class is marked as disjoint from its sibling classes in the class 
hierarchy, as shown in Eigure 3.10. We do not make them disjoint because the reasoner will 
fail. We make them disjoint because they truly are disjoint from each other. That informa¬ 
tion is used by the reasoner for its processing. The Human class is seen as a subclass of 
DeliveryMethod, disjoint with siblings Package, Vehicle, see Eigure 3.11. It is not 
too difficult to understand how the tree can assist in visualizing the hierarchy of a class such as 
DeliveryMethod. The class DetectionMeans is a means of finding an lED, but is not 
explicitly used in defining an LED. The lEDIndicators class is a depiction of objects that a 
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Figure 3.11: Human class shown with its disjoint sibling classes. 
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#Trash 

# DeliveryMethod 

# DetectionMeans 

lEDIndicators 

9 Baneries 

# DisturbedSoil 
#IsolatedBox 

9 ManWithCellPhone 
9MetalPlate 
9 MouseTrap 

▼ 9 Munitions 

T 9NonShellMilitary 
9 Grenade 
9RoundRPG 
9 RoundSmallArms 
▼ 9ShellMilttary 

9ShellArtillery 
9ShellMortar 
95odaCan 
9 Springs 

# SteelTubes 

▼ •Vehicles 

• Abandoned 

• Occupied 
p • Wires 


V Location 

►- 9Trigger 


Figure 3.12: lEDIndicators class shown with with its subclasses contained in the yellow 
box. 


user may be able to see when utilizing a UAS such as a Raven (see Figure 3.12). The Trigger 
class represents means to initiate an lED, see Figure 3.13. It would be plausible for a user of 
a UAS to see these types of objects while scanning an NAI for an LED. In Trigger class the 
subclass Cellphone is highlighted, notice that it is disjoint with its siblings. 

3.5.4 Defining Properties in lED Ontology 

Properties are what relate an individual to another individual in the ontology. An individual is 
an instance of a class. Eor example if there was a class “Dog” containing an individual named 
“Rascal” and he belongs to individual “John” from class “Owner,” “John” would share the 
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Figure 3.13: Trigger class with subclass CellPhone highlighted. 


object property “hasPet” with individual “Rascal.” In predicate calculus this takes on the form 
hasPet(John,Rascal). The same logic applies to defining an lED. There are four object 
properties that make up an lED ontology. The tutorial states “properties link individuals from 
the domain to individuals from the range'" [43, 33]. Below are the four object properties defined 
in this ontology: 

• hasDeliveryMethod Domain: lED Range: DeliveryMethod 

• hasIEDIndicators Domain: lED Range: lEDIndicators 

• hasLocation Domain: lED Range: Location 

• hasTrigger Domain: lED Range: Trigger 

The object property hasDeliveryMethod has three subproperties: 

• hasHumanDeliveryMethod Domain: lED Range: Human 

• hasPackageDeliveryMethod Domain: lED Range: Package 

• hasVehicleDeliveryMethod Domain: lED Range: Vehicle 

The hasLocation object property is selected in the Object Properties tab (see Figure 3.14) 
The Functional box checked implies that each individual in the lED class can be related 
to only one individual from Location class. The second class of properties in an OWL- 
Ontology are datatype properties. Datatype properties “...can be used to relate an individual 
to a concrete data value that may be typed or untyped” [43, 76]. The two data properties are 
hasIEDIndicatorName and isConf irmed, which are further summarized below: 

• hasIEDIndicatorName Domain: lEDIndicators Range: string 
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Figure 3.14: The hasLocation object property is selected with Domain IED and Range 
Location. The Functional box is checked as well. 


• isConf irmed Domain: IED Range: boolean 

The hasIEDIndicatorName range “string” will allow user to manually input some type of 
name for an lEDIndicator such as “dirt, iPhone, iron pipe.” The isConf irmed allows 
the user to set if an IED indivdual is a confirmed IED (isConf irmed value equals “true”) or 
not a confirmed IED (isConf irmed value equals “false”). 

3.5.5 Deeper Look in to IED Class 

Now that the definition of classes and properties has been given, it is time to look further into 
IED class. The idea is to have the UAV sensor “see” objects (“clues”) in its environment and the 
operator would take the “clues” and classify something as an IED. In order for something to be 
classified as being a member of the IED when using Protege-Owl, the class has to be necessary 
and sufficient aka Defined Class [43, p. 55]. A necessary condition is one that needs to be 
present to be able to make the classification, but may need other conditions [43, 53]. A suffi¬ 
cient condition is one that by itself is enough to make the classification without needing other 
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Figure 3.15: Necessary and Sufficient description. Taken from Pizza Tutorial [43, p. 56]. 


conditions to be true [43, 56]. See Figure 3.15 for an illustration of necessary and sufficient 
conditions. A class that is defined is indicated by white lines in the orange node circle [43, 57]. 

The necessary and sufficient criteria for lED class is seen in Figure 3.16. The word some repre¬ 
sents an existential restriction. This says that there is a relationship between individuals of lEDs 
that has “at least one” relationship along the property (for example) “hasDeliveryMethod” 
to an individual that is a member of the class “DeliveryMethod” [43, 59]. The “and” rep¬ 
resents an intersection where all of the object properties overlap. Next, we will look at the 
three different types of lEDs based on how they are delivered: Package (PackagelED class), 
Suicide/Human (SBIED class), and Vehicular (VBIED class). 

The PackagelED class is a subclass of hasPackageDeliveryMethod and lED and 

it inherits the same four characteristics of an lED based on being a subclass of lED. The 
PackagelED class represents delivery by some package, one that is not a suicide bomber 
(SBIED) or vehicular (VBIED). One can see that it is also disjoint with its siblings SBIED and 
VBIED (see Figure 3.17). The SBIED class is a subclass of lED and hasHumanDeliveryMethod 
some Human, and like its sibling PackagelED it inherits the four properties that make 
an lED an lED. It is also disjoint with VBIED and PackagelED (see Figure 3.18). The 
purpose of SBIED is to represent characteristics of a suicide-borne LED. A suicide borne 
lED delivery could be performed by a child (ChildSBIED), Woman (FemaleSBIED) or 
a man (MaleSBIED). Since ChildSBIED is a subclass of SBIED it inherits the proper¬ 
ties of SBIED, which is defined in the middle of the “Description: ChildSBIED” box labeled 
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Figure 3.16: The “Equivalent To” box is highlighted showing what must be true in order for an 
individual to be a member of the lED class. 

“Sub Class of (Anonymous Ancestor).” The property that explicitly defines ChildSBIED is 

hasHumanDeliveryMethod and qualifies the delivery method as a child with the “some 

child” clause. It is also disjoint with its siblings MaleSBIED and FemaleSBIED. The classes 

MaleSBIED and FemaleSBIED are similar to ChildSBIED with hasHumanDeliveryMethod 

qualified as Female and Male, respectively. The VBIED class is a subclass of lED and hasVehicleDelivery 

and like its siblings PackagelED and SBIED it inherits the four properties that make an lED 

an lED. It is also disjoint with SBIED and PackagelED (see Figure 3.19). The purpose 

of VBIED is to represent characteristics of a vehicle-borne lED. The class Conf irmedlED 

is to be used when an operator sees characteristics of an lED (via UAV) and calls EOD, 

who then “confirms” that it is a real lED. It inherits the properties of lED and has the value 

isConf irmed with a “true” value. The Conf irmedlED is disjoint with its siblings SBIED, 

VBIED, and PossiblelED (see Figure 3.20). If the lED is not confirmed, it will then be 
classified as a “PossiblelED,” which is discussed next. 
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Figure 3.17: PackagelED shown. 
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Figure 3.18: SBIED shown. 
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Figure 3.19: VBIED shown. A vehicle borne lED delivery happens by a vehicle via 

hasVehicleDeliveryMethod. 



Figure 3.20: Conf irmedlED shown. 
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Figure 3.21: PossiblelED shown. 



Figure 3.22: WeakBelief lED shown. 


The PossiblelED is a subelass of lED and has the property isConf irmed with a “true” 
value. In theory if an lED is not a “ConfirmedlED” it will always be elassified as a "Pos¬ 
siblelED" (see Eigure 3.21). A WeakBelief lED inherits all of the properties of a type 
PossiblelED with the exeeption of its own speeifie requirement in “Equivalent to” box 
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(circled on top portion of “Description” window, see Figure 3.22). A WeakBelief lED is 
a type of lED that has a minimum of 1 lED indicator and a maximum of 2 lED indicators. It 
is using a new restriction called the universal restriction only. The universal restriction states 
“zj a relationship exists for the property then it must be to individuals that are members of a 
specific class” [43, p. 60]. The goal is to create an individual with a minimum of 1 and maxi¬ 
mum 2 “lEDIndicators” and have the reasoner classify it as a “WeakBelieflED.” The minimum 
and maximum are a type of cardinality restriction. The tutorial states: “A Cardinality Restric¬ 
tion specifies the exact number of P relationships that an individual must participate in” [43, 
p. 73]. The assumption is that you would need a few indicators such as loose soil and wires 
together at some specific location along a route of travel to have a UAS operator to possibly 
take a closer look at what they are scanning on the ground. If more than two indicators are 
found, the reasoner will classify the object as a “StrongBelieHED,” which is described next. 
A StrongBelief lED inherits all characteristics of a PossiblelED with the addition of 
a third “lEDIndicator.” Therefore in the “Equivalent To” box the addition of object property 
hasIEDIndicators min 3 lEDIndicators is necessary. The idea is to show that an 
operator that sees “loose soil,” “box,” and “wires” would probably think that there is a higher 
suspicion of being a true lED versus only seeing two or fewer indicators. The properties of 
a StrongBelieflED can be found circled in the “Description: StrongBelieflED” box, see 
Eigure 3.23. 



Eigure 3.23: StrongBelieflED shown. 
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Figure 3.24: ied_0 individual shown. 



Figure 3.25: disturbedsoil_l individual being assigned type DisturbedSoil. 


3.5.6 Defining Individuals in lED Ontology 

The study will now look at creating individuals in the ontology that will allow the reasoner to 
show if the created individual can be classified as a “PossiblelED,” “StrongBeliefEED,” “Weak- 
BelieflED,” or “ConfirmedlED.” Individuals can be created in the “Individuals” tab. All indi¬ 
viduals in Protege are identified with a purple diamond and are written in lowercase. In order 
for the reasoner to classify (infer) an individual as being a member of a certain class, the class 
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of which it is a member needs to be a “defined” elass, otherwise the reasoner will not properly 
elassify (infer) its relationship to a partieular elass. First, the individual ied_0 is ereated, see 
Figure 3.24. It is given the type lED and Data property assertion isConf irmed with value 
“false.” This represents an objeet that has been deteeted but no indieators have been identified. 
The seeond lED individual will have with it two LED Indieators: “disturbed soil” and “wires.” 
These indieators will need to be created individually so we ean assign them as objeet proper¬ 
ties to individual ied_l. Eirst lED Indieator is named disturbedsoil_l, assigned elass 
type DisturbedSoil and given hasIEDIndicatorName “dirt” string. To assign the type 
lED eliek on “Types” “-r” sign and seleet “Class Hierarehy” and select “ok.” (see Eigure 3.25). 
Next, assign data property assertion type string “dirt” to disturbedsoil_l indieator. See 
Eigure 3.26 for assigning “dirt” to indicator disturbedsoil_l. One eould change “dirt” to 
“dog” and the reasoner would not eare, assigning “dirt” makes it easier for the user to follow 
along. The seeond lED Indieator is named wires_l it is assigned the lEDIndicator 



Eigure 3.26: disturbedsoil_l indieator being assigned string “dirt” shown. 


subelass Wire and given the data property assertion string “wire” (see Eigure 3.27). The see¬ 
ond lED individual, ied_l is like ied_0 exeept the individuals disturbedsoil_l and 
wires_l are assigned as “objeet property assertions,” and sinee this is not a “confirmedlED” 
it is assigned data property isConf irmed with value “false.” (see Eigure 3.28). To assign 
the lED Indieators seleet “Objeet property assertions” underneath “property assertions win¬ 
dow” and click on “-r” sign. Next assign the two indicators to ied_l (see Eigure 3.29). The 
third and final indieator is defined with objeet property hasIEDIndicator with type string 
and individual assigned the name as isolatedbox_l to represent a box alongside the road. 
There is no change in how you assign it a type and data property assertion. See Eigure 3.30 
for isolatedbox_l individual sereenshot. The third lED individual is ied_2 it has 3 lED 
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Figure 3.27: wires_l individual shown. 



Figure 3.28: ied_l individual shown. 



Figure 3.29: Assigning lED Indieators to ied_l. 


Indicators and “isConfirmed” value set to “false” (see Figure 3.31). This is an individual that 
an operator has been able to associate three characteristics of this “Possible lED.” 
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Figure 3.30: isolatedbox_l individual shown. 


Since it is not confirmed yet, the data property isConf irmed is set to “false.” The fourth and 





Figure 3.31: ied_2 individual shown. 


final lED individual is ied_3, which is just like ied_2 except this lED has been confirmed 
by EOD to be a legitimate lED, therefore the isConf irmed data property assumption is set 
to "true" (see Figure 3.32). 
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Figure 3.32: ied_3 individual shown. 



Figure 3.33: Reasoner elassifies objeet “Possible lED.” based on its objeet and data properties. 


3.5.7 Classifying an lED Using the Reasoner 

The experiment will now model the behavior of a UAS’s ability to make a deeision based on the 
information that it reeeives from its sensors. In this experiment, the sensor (UAV) is eolleeting 
data that falls into the eategories of ‘TED Indieators.” Pieees of information that an operator 
may or may not be able to see using the UAS is represented as individuals. The reasoner is 
used to establish the level of eonfidenee in what is seen based on the amount of information 
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the operator is able to see using his/her UAV. The UAV is flying looking for threats along the 
way. The operator detects an object (called ied_0), however, he/she cannot identify what it 
is. Because ied_0 does not have any indicators the reasoner should and does classify this 
object as a "PossiblelED" (see Figure 3.33). As the operator continues to look at the object 
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Figure 3.34: Reasoner classifies object as “Strong Belief lED.” based on properties associated 
with ied_2. 


they see lED indicators such as disturbed soil, wires, and now a box (making the user feel more 
confident about what is seen) causing the reasoner to classify this object (now called ied_2) as 
a “Strong Belief lED” (see Figure 3.34) since there are three indicators. The convoy commander 
cordons off the area and calls for the EOD to investigate this strong belief, possible lED. Once 
EOD arrives, having looked at the same characteristics that the operator has, confirms that object 
(now called ied_3 is a “real lED” and classifies it as a “Confirmed lED” (see Figure 3.35).This 
device is neutralized by EOD and a highly possible catastrophic kill is prevented. 
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Figure 3.35: The “possible, strong belief IED” has been confirmed an IED by explosive ord¬ 
nance disposal (EOD). 


3.6 DESIGN OF EXPERIMENTS 

The goal of Design of Experiments is to see if the effects of training on mission success can be 
shown in COMBATXXI utilizing the HTNs and UAV Sensor model. The mission objective is 
to arrive at Outpost X-Ray safely (as mentioned in section 3.2). The only true IED (located in 
NAI #2) detonates with probability 0.80 and will always kill the second vehicle in the convoy 
when detonated, the other three NAIs each have a single non-IED object. The mission will be 
over if: (1) Convoy reaches final destination without hitting IED (Mission Complete or MC) 
or (2) Convoy hits IED (Mission Eailure). Success (MC) can only happen if IED is detected 
and defeated (UAS used effectively) or IED does not go off (probability 0.20) given IED is 
undetected (worse case). The UAV sensor [40] has a likelihood of detecting the object with 
probability 0.50 if the range from the sensor to the IED (r) is 110 meters and probability 0 if r 
is 220 meters or greater. Time to clear an IED is 60 minutes. 
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The factors affecting mission success are False Positive (a) and False Negative (j3), with levels 
ranging from 0.0 to 1.0. Experiments run at six values for each (0.0, 0.2, 0.4, 0.6 0.8, 1.0), for 
a total of 36 design points. Each design point is run 100 times for a total of 3600 observations 
(n). Below are the definitions for Ealse Positive and Ealse Negative: 

• If Ealse Positive (a) 0.0 then UAS ALWAYS identifies a non-IED object as a non-IED. 

• If Ealse Positive (a) 1.0 then UAS ALWAYS identifies non-IED as an lED. 

• If Ealse Negative (/3) 0.0 then UAS ALWAYS correctly identifies lED as an lED. 

• If Ealse Negative (j8) 1.0 then UAS ALWAYS incorrectly identifies lED as a non-IED. 

Best case is when alpha and beta are 0.0 and 0.0. This represents an operator that both correctly 
classifies an object as being an lED or something that is truly not an lED (trash), reducing risk 
(less time exposed), and saving resources (UXO clearing team not called). 

Worst case is when alpha and beta are 1.0 and 1.0. This represents an operator who always 
incorrectly detects an object as an lED and unnecessarily wastes resources to “clear” a non- 
IED, adding more time to convoy being exposed outside the wire, while at the same time always 
misidentifying real lEDs, leading to a high failure rate. 

Metrics to measure the effects of alpha and beta are: 

• Mean Mission Success Rate 

• Mean Time to Complete Mission I Mission Complete 

• Risk = 1/MC% X Mean Time to Complete Mission I Mission Complete 

3.6.1 Summary 

The concept of using an ontology and implementing it in order to demonstrate a different ap¬ 
proach in measuring the sensing ability of a UAS is discussed. The DOE will determine if it 
is possible to model the positive and negative effects of being trained and untrained (changing 
values of alpha and beta) given the UAV sensor model detects the object. In the next chapter, 
the research will perform an analysis on data to be collected. 
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CHAPTER 4: 
ANALYSIS 


4.1 INTRODUCTION 

We demonstrate the utility of our approach through analysis of the proof of concept scenarios. 
The findings show how the scenario results are sensitive to changing parameters False Positive 
(a) and False Negative (/3) in our sensor model. This proof of concept scenario would be useful 
to a decision maker interested in evaluating the potential impact of training on the effective use 
ofUAVs. 


4.2 DESIGN OF EXPERIMENTS ANALYSIS IN 
COMBATXXI 

The analysis will investigate the effects of a and j8 at six levels each (0.0, 0.2, 0.4, 0.6,0.8,1.0), 
mentioned earlier in chapter 3 “Methodology” The goal is to identify what combinations of 
alpha and beta give us the highest Mean Mission Success Rate, lowest Mean Time to Complete 
Mission I Mission Success, and to help quantify Risk. 


4.2.1 Mean Mission Success Rate 

This section is about measuring the mean success rate for the 3600 observations. A heat map 
is utilized to communicate results. Boxplots help to show noise and meaning to support the 
findings on ct’s and /3’s effects on Mission Success Rate. Looking at Figure 4.1 we can see 
that the highest completion rate is 0.84 and occurs when /3 is 0.0, and is independent of a 
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Figure 4.1: Heat Map of Mission Success Rate versus parameters False Positive (a) and False 
Negative (/3). Notice that the Mission Success Rate does not change as alpha increases from 
0.0 to 1.0, which demonstrates that the False Positive parameter a does not have an effect on 
mission success. Mission failures occured even with /3 at zero because on some trials the UAV 
never sees the lED, and as a result the LED was not identified. 
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Figure 4.2: Boxplot of Mission Success Rate versus False Positive Rates. Notice that the Mis¬ 
sion Success Rate does not change as alpha increases from 0.0 to 1.0. This shows that a does not 
have an effect on mission success since False Positive represents the identification of non-IED 
objects. 


Boxplots of Mission Success Rate versus False Negative Rates 
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False Negative IS) 


Figure 4.3: Boxplot of Mission Success Rate versus False Negative Rate (/3). Notice that the 
Mission Success Rate decreases as /3 increases from 0.0 to 1.0. There is no variance in the 
success rate either, which is why the boxes appear as lines instead of boxes per earlier boxplots 
when looking at Mission Success versus False Positive Rate. This shows that /3 has a great 
effect on mission success rate versus a. 


levels. The lowest average of completing mission is approximately 0.20 and 0.19 when /3 is 
1.0, independent of a levels. The decrease in mean mission success as /3 increases is caused by 
a higher probability of incorrectly identifying the lED in NAI #2 as a non-IED. Since the LED 
has a probability of 0.8 of detonating, that is why the success rate is 0.20 when /3 equals 1.0. As 
the Ealse Positive value increases from left to right the success rate generally remains constant. 
It is only as we increase j8 that there is a difference in mission success rate, concluding that j8 
has a strong influence on the likelihood of completing the mission. Eooking at the first boxplot 
(see Eigure 4.2), one can see that the Ealse Positive (a) does not have an effect on the mission 
success rate since the boxplots share the same dimensions, respectively. The Mission Success 


54 




























































False Positive (a) Parameter 



0.0 

0.2 

0.4 

0.6 

0.8 

1.0 

0.0 

125.00 

145.00 

166.43 

196.43 

216.43 

241.43 

0.2 

123.19 

141.02 

163.73 

192.92 

214.81 

239.13 

0.4 

119.06 

138.01 

158.01 

185.38 

205.38 

227.48 

0.6 

116.00 

134.26 

156.43 

183.82 

204.69 

225.56 

0.8 

101.61 

124.43 

136.78 

165.74 

184.36 

209.19 

1.0 

69.44 

91.70 

113.80 

139.06 

161.17 

186.43 


Mean Time to Complete Mission | Mission Success 


Figure 4.4: Heat Map of Mean Time to Complete Mission I Mission Success for different values 
of False Positive (a) and False Negative (/3). Mean time to complete the mission takes the 
longest when a is 1.0 and /3 equals 0.0. Mean time for a successful mission increases as a 
increases and decreases as /3 increases. 


Rate is very close or right above 50% as a increases from 0.0 to 1.0. Continuing on with the 
second boxplot, the False Negative Rate (/3), mission success decreases as /3 increases from 0.0 
to 1.0 (see Figure 4.3). 

This visual helps to show that in the model that False Negative Rate (/3) has a strong effect on 
mission success. 

4.2.2 Mean Time To Complete I Mission Success 

Now the study will look at the mean time to complete the mission given mission success occurs. 
Looking at the heat map in Figure 4.4 it appears that the mean time to complete mission given 
mission success is influenced more on a than /3. Mean time to complete mission is highest at 
241.43 minutes when a = 1.0 and /3 = 0.0. This makes sense; the operator will always identify a 
non-IED as an lED when a = 1.0. The lowest mean time to complete mission of 69.44 minutes 
is at the opposite corner when a = 0.0 and /3 = 1.0. This number can be misleading because in 
this case, the UAV operator will always identify a piece of trash as trash (a = 0.0), but when 
/3 is equal to 1.0, the operator will always incorrectly identify an LED as a non-IED. Therefore 
in this case the convoy will never stop to handle a potential threat. The only reason there is 
any success in this case is because there is a 0.20 chance the lED will not detonate and it is in 
these “lucky” cases that the mission is completed. Now examining the Mission Complete Time 
boxplots (see Eigure 4.5) it appears that the average time to complete the mission does increase 
as Ealse Positive Rate (a) increases from 0.0 to 1.0.; this makes sense in our model given that 
we stated earlier that if a is 0.0 it would always identify a non-IED object as a non-IED. Also 
when a is 1.0 the UAS operator always identifies non-IED as an lED, leading to additional 
time spent on a mission and exposing onself to more harm. Examining Eigure 4.6 it appears 
that mission completion time does not vary as much and remains constant (at /3 value increases), 
proving that in the model, the Ealse Negative Rate (/3) does not have as much influence for mean 
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BoKplois Of Mission Complete Time versus False Positive Rates 



Figure 4.5: Boxplot of Mission Completion Time versus False Positive Rates. Notiee that 
median time to eomplete mission inereases as the False Postive Rate (a) inereases. There 
appears to be a linear relationship; the varianee for eaeh value of a appears to be equal to one 
another as well. This means that a will always have an effeet on amount of time it completes 
the mission. 



Figure 4.6: Boxplot of Mission Complete Time versus False Negative Rate (/3). The False 
Negative parameter /3 does not have as much of an effect on average time it takes the convoy 
to complete the mission. Notice that the Mission Completion Time is not heavily influenced on 
the change in /3 from 0.0 to 1.0. A time of 150 minutes could be found for each /3 value. Only 
when the value of 0.8 is reached is there a drop in median time of completing the mission. This 
is because the observer has a higher probability of incorrectly identifying the lED as a non-IED, 
resulting in fewer times to successfully complete the mission and have an observed time. 


mission completion time as the False Positive Rate (ct). 


4.2.3 Measuring Risk 

Risk is something all commanders must take when utilizing the U.S. Army’s most valuable 
asset: soldiers. As a means to assess risk, we can combine the considerations of mission success 
rate and completion time. We task risk to be: 
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Risk = 1 / MC% * Mean Time To Complete Mission 


Mission 


Success 


Figure 4.7: Heat Map of Risk for different values of False Positive (a) and False Negative (/3). 
Lowest risk takes place at a and /3 being 0.0, 0.0. Given the lED is detected, the user has 
capability to correctly identify the lED and does not waste time clearing non-IEDs. When a, 
/3 is 1.0, 1.0, risk is highest (less likely to correctly identify lED and more likely to incorrectly 
identify non lEDs as being lEDs). 


Risk = \ / MC%x{MeanTimetoCompleteMission\MissionComplete) (4.1) 

Eigure 4.7 shows risk as a function of a and /3. It is the most interesting of the three heat maps. 
This measure of risk attempts to combine the risk of not identifying the lED with the inherent 
risk associated with being out in the open for an extended amount of time. Eigure 4.7 confirms 
that this characterization of risk captures both aspects of the risk encountered by convoys. We 
expected the most dangerous situation to be when a is 1.0 and j8 is 1.0, when the operator 
always misidentifies objects as being real lEDs and never identifies the real lEDs as a real 
lED, this is what we can see in the heat map. At the opposite corner when a and /3 are 0, 
respectively, risk measures at 148.81. This is the best case scenario because an lED is always 
classified as an lED and non-IEDs (trash) are always identified as trash, minimizing the amount 
of time a convoy must spend on the route outside of “friendly” territory while still reducing the 
vulnerability to damage from lEDs. 

4.3 SUMMARY 

The results above show that it is possible that a UAS (like the Raven) may improve deployable 
force protection capabilities if the assumptions hold true in the real world. It is possible to 
measure success and time to complete a mission with different combinations of a and /3. The 
heat maps provided valuable insight on the ramifications of each a and /3 level. The boxplots 
gave reassurance in the validity of the heat maps by showing differences the parameters do or 
do not have. Risk gave further understanding into the importance of correct versus incorrect 
identification of objects, and the effects of wasting time clearing non-IED threats. Next, the 
study will give a conclusion of using the new STA model and the idea of combining KR through 
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an ontology made using special software. 
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CHAPTER 5: 
CONCLUSION 


5.1 OUTCOMES 

We demonstrated the applieation of the new STA model in a taetieal eonvoy seenario in 
COMBATXXI. We showed the ability to model a UAS in a working environment is fundamental 
to a study eoneerning taetieal eonvoy operations. A design of experiments and post analysis 
quantifies the sensitivity of the measures of effeetiveness of sueeess to eonditions eontributing 
to variability in UAS performanee. 

5.1.1 What Does This Mean? 

Behaviors for UASs ean be designed and developed using Behavior Studio Interaetive Design 
Environment. HTNs were ereated to replieate the thought and aetion proeess of a eonvoy as it 
travels down a path wary of threats sueh as lEDs, with respeet to the use of UAVs. The simula¬ 
tion allows for some analysis to determine if taetieal eonvoy operations using a deployable foree 
proteetion asset (Raven UAS) eould be studied in COMBATXXI using the UAV sensor model, 
and assoeiated dynamie behaviors without the relianee of nonadaptive seripting and eompound 
orders eurrently in use. Eaetors sueh as Ealse Positive and Ealse Negative allows us to see how 
an operator’s skill level ean affeet the outeome of a taetieal eonvoy operations in SWA. It was 
found that a eonvoy experieneed less risk and obtained a higher frequeney of eompleting the 
mission when they eould inerease the likelihood of identifying an lED objeet as an lED and 
deereasing the likelihood of misidentifying non-IEDs. 

5.1.2 Are There Any Advantages to UAS? 

Given the eonstraints, conditions, and limitations of the sensor model and COMBATXXI, it 
was shown that utilizing the UAS gave a higher likelihood of success. We also showed that 
qualitative factors such as risk could be be controlled with the use of a UAS. 

5.1.3 Have We Modeled UAS properly? 

Due to the dynamics of electro-optics (EO) sensors, the human eye and thought process, it is 
naive to say the Raven UAS was modeled properly, in this study. This study demonstrates that it 
is possible to model the complexities of a UAS in a complex simulation such as COMBATXXI. 
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5.1.4 Ontology Pros and Cons for Knowledge Representation with 
COMBATXXI 

The ontology showed that it is possible to express knowledge semantically and have a reasoner 
classify a threat based on the clues (lED indicators) that a human would detect using a UAV 
such as the Raven. It is important to note that the cues used in the ontology can be represented 
in a model like COMBATXXI. 

5.1.5 Future Work 

The work presented in this thesis is an initial look at possible uses of combat models such as 
COMBATXXI. This work can be continued in many ways. Below are some possible areas that 
merit further investigation. 

Develop extensions and support structures to allow COMBATXXI to be more amenable for use 
in studies that use the DOE methodology. This would allow it to be used in studies to look at 
complex parameter spaces that are not possible with the current structures. 

Investigate the integration of ontology based KR systems into combat models such as 
COMBATXXI. By adding such structures, a wide range of investigation is made possible. These 
can range from identification of threats that take into consideration both observations and other 
information, such as past activity, to being able to reason about motives of opposing entities. 
The use of ontologies could also support more robust behaviors that can be used in a wider set 
of circumstances, which would facilitate building general purpose behaviors that can be reused 
in many scenarios. 


60 



APPENDIX A: 
JOHNSON CRITERIA 



Figure A.l: Normalizing resolved line pairs for critical target dimension. After [44, p. 264] 
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Figure A.2: Number of minimum line pairs required for the four detection, orientation, recog¬ 
nition, identification. From [44, p. 264] 
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APPENDIX B: 

CONCEPT OF OPERATIONS 


Mission 

In support of 2nd Platoon (PLT), Alpha Company (Co.), 2-37 IN (Infantry), 4th squad provides 
security and logistic runs in partnership with the 3rd LNA Battalion to support operations for 
the local populace while protecting the Dam. 

Situation 

2nd Platoon, A CO, 2-37 IN, conducted a relief in place (RIP) of the combat outpost (COP) 
three months ago. 2nd Platoon is scheduled to RIP with 1st Platoon within the next week and 
will assume FOB security at the CO HQ and serve as the CO reserve. Besides working and 
training the LNA troops, the platoon is also responsible for protecting the Dam workers that 
live on the COP. The missions are broken down into equal parts and each squad will rotate 
responsibilities to reduce complacency. The four task are (1) Entry Control Point [3 personnel x 
3 eight hour, shifts = 1 squad], (2) Force Protection [3 Towers /OP points x 3 eight hour shifts = 
1 squad], (3) Dam Observation Post [3 personnel x 3 eight hour shifts = 1 squad], and (4) local 
security patrols and quick reaction force = 1 squad. For each squad there is one FNA platoon 
supporting to be the immediate face to the community. 4th squad is equipped with 1 x Raven 
1 IQ B UAS. Four of the 11 soldiers in the squad are qualified Raven operators. 

Commander’s Intent 

2nd Platoon partnered with 3rd Battalion FNA will protect the population from insurgents, men¬ 
tor the FNA partners, and protect the FNA partners in contact with insurgents. This partnership 
will maintain force protection at all times and provide over watch to the Dam to safeguard the 
area’s power supply. 4th Squad will perform logistic runs in support of (ISO) 2nd Platoon, A 
CO, 2-37 IN. 

Enemy 

Threat forces consist of 300 insurgents equipped with RPG, PKM, AK-47, HMG, AT-3, SPG-9, 
SA-I6 and 82mm mortar. The main threat consists of 3 x PFTs with two supporting efforts. 
Each PET has the ability to emplace 2 x lEDs. There are reports of 8 to 10-man insurgent teams 
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equipped with RPG, AK-47. There are also reports of possible lED emplacements along MSR 
WEST VIRGINIA. 

B.0.6 Terrain 

Open desert to desert mountains with adjacent urban structures. 

B.0.7 Troops Available 

Coalition and Host Nation Eorces: 1 x U.S. Infantry squad equipped with organic direct fire 
weapons, with support from 120mm mortars. 21 soldiers from the ENA company and 16 from 
the ENP. 

B.0.8 Time 

0800, day, clear. 

B.0.9 Civilian 

Civilian populace is either controlled or intimidated by enemy operating within the area of 
operations (AO). 
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APPENDIX C: 

CONVOY MOVE IN FORMATION 


1 =============================== 

2Name: ConvoyMoveInFormation 
3AllowMsg: true 
4Node Type: DEFAULT 

5 Is Code File: false 

6 Import: 

7 Datamap: 

8 formation=>j ava . lang . S tring 

9 route =>cxxi. model. objects . features .CMPolyline 

10 NAI_phaseLines=>java . util . ArrayList 

11 UAS_routes=>j ava . util . ArrayList 

12 falseNegativeRate=>[Ljava . lang . String ; @7b449bld 

13 falsePositiveRate=>[Ljava . lang . String ; @5523cc24 
14Metadata: 

15Code: 

16 =============================== 

17 Name: i nit Info 

18 AllowMsg: true 

19 Node Type: DEFAULT 

20 Is Code File: false 

21 Import: 

22 Datamap: 

23 Metadata: 

24 Code: 

25 if _gt_activeNode . getVar ( " i sIni ted " ) == None: 

26 _gt_acti veNode . putVar (" i s I n i t e d " , 1) 

27 _htn_precon_ret=l 

28 =============================== 

29 Name: isCommander 

30 AllowMsg: true 

31 Node Type: DEFAULT 

32 Is Code File: false 

33 Import: 

34 Datamap: 

35 Metadata: 

36 Code: 
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37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 


if state . isCommander 0 : 
_htn_precon_ret=l 


Name: setup 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

from cxxi . model import CombatXXlModel 
from os import access 
from os import F_OK 
from os import W_OK 
from sys import stderr 
try: 
logfile 
writeOK 

except NameError: 

# open the log file in the same place CXXI puts the other log files 
logfilePathName = s tr (CombatXXlModel. getOutputD irectory () ) + "/DFP. 

log " 

writeOK = True 
try: 

logfile = open (logfilePathName , "w" ) 
except lOError: 

print »stderr ,"\n \nWarning^ ! ! ! !^Could^not^open^log^file^to^write^— 
^log^will^not^be^output .\n\n" 

print »stderr fi 1 e ^may^be^open^in^another^ 

application .\n\n" 

writeOK = False 
if writeOK: 

_gt_activeNode . putVar( " logfile " , logfile ) 

# get the rep number for this run 

repNum = CombatXXlModel. getReplicationNumber () 

_gt_activeNode . putVar ( "repNum" , repNum) 

# set up the holder in the borg to hold the non—ied names 
name = "notlED" 

notlED = [] 

borg . add Attribute (name , notlED, _gt_acti veNode ) 
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75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 

107 

108 


Name: initCommander 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

from HTN import UtilityFuncsExp 

# s t at e . addControlMeasure ( nai) #adds control measure for CXXl to pay 
attention to . 

for cm in _gt_activeNode . getParam ( " NAl_phaseLines " ) : 

state . addControlMeasure (cm. getName () ) 
speed = 2 

# scehdule the event to get us going 
UtilityFuncsExp . scheduleEvent ( 

info . getMyAssignedName () , 

" GoalTracker_MoveOut" , 

0.001 , 
speed ) 


Name: addReplanTriggers 
AllowMsg: true 
Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

goalContainer. getCurrentExecutingStack() . addReplanTrigger(" 
AtAControlMeasure" ) 

goalContainer. getCurrentExecutingStack() . addReplanTrigger(" 
GoalTracker_MoveOut" ) 

goalContainer. getCurrentExecutingStack() . addReplanTrigger(" 
GoalTracker_UASPickedUp" ) 

goalContainer. getCurrentExecutingStack() . addReplanTrigger(" 
EmbarkComplete" ) 

goalContainer. getCurrentExecutingStack() . addReplanTrigger(" 
DamageOccurredlnMyUnit" ) 
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109 goalContainer. getCurrentExecutingStack() . addReplanTrigger(" 
GoalTracker_ResumeMovingAtSpeed" ) 

110 goalContainer. getCurrentExecutingStack() . addReplanTrigger(" 
StoppedMovement" ) 

111 =============================== 

112 Name: doNothing 

113 AllowMsg: true 

114 Node Type: GOAL 

115 Is Code Eile: false 

116 Import: 

117 Datamap: 

118 Metadata: 

119 Code: 

120 

121 ^^^^^At^ thi s ^point^only ^the^commander^does^any thing^so^ if ^the^ tree ^i s ^ 
as signed^ to^someone^who^i s 
122^^^^^not^ the ^commander ,^just^end^the^tree . 

123^^^^^NOTE^— ^ if^this^tree^is^to^be^used^if^there^is^attrition^this^should^ 
not^be 

124^^^^^done^ this ^way^and^there^should^be^a^way^to^keep^the^tree^around^in^ 
case^the^current 

125^^^^^" non—commander i s ^promoted^to^command^via^ attrition . 

126 ’ ’ 

127 =============================== 

128 Name: events 

129 AllowMsg: true 

130 Node Type: DEEAULT 

131 Is Code Eile: false 

132 Import: 

133 Datamap: 

134 Metadata: 

135 Code: 

136 =============================== 

137 Name: isGoalTrackerEvent 

138 AllowMsg: true 

139 Node Type: DEEAULT 

140 Is Code Eile: false 

141 Import: 

142 Datamap: 

143 Metadata: 

144 Code: 
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145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 

161 

162 

163 

164 

165 

166 

167 

168 

169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 

181 

182 

183 

184 


if state . getLastTrigger () . startswith ("doGoalTracker_") : 
_htn_precon_ret=l 


Name: isMoveOut 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

if state . getLastTrigger 0 == " doGoalTracker_MoveOut" : 
_htn_precon_ret=l 

printMessage( "GOAL^TRACKER^EVENT"+ state . getLastTrigger () , True) 


Name: moveOut 
AllowMsg: true 
Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

from cxxi . model . behavior import OrderU ti 1 i t ie s 
from java, util import Vector 

from mtry . cxxi . model. HierarchicalTaskNetwork import HTNUtilities 

formation = _gt_activeNode . getParam (" formation " ) 

route = _gt_activeNode . getParam (" route " ) 

printMes s age (" formation^ i s + formation, True) 

params = state . getLastTriggerParams () 

speed = f 1 o at ( params [ 0]) 

ord = HTNUtilities . _py_getMoveOrderFromRoute ( route , speed, formation 

) 

orders .addOrder(ord) 
startTime = state . getSimTime () 

_gt_activeNode .putVar(" startTime" , startTime) 


Name: isGoalTracker_UASPickedUp 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
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185 

186 

187 

188 

189 

190 

191 

192 

193 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

204 

205 

206 

207 

208 

209 

210 

211 

212 

213 

214 

215 

216 

217 

218 

219 

220 

221 

222 

223 


Import: 

Datamap: 

Metadata: 

Code: 

if state . getLastTrigger 0 == " doGoalTracker_UASPickedUp " 
_htn_precon_ret=l 


Name: pickedUpUAS 
AllowMsg: true 
Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

from HTN import UtilityFuncsExp 

# we have picked up the UAS, so we should continue 
observations = s tate . getLastTriggerParams () [0] 
if observations . isEmpty 0 : 

UtilityFuncsExp . scheduleEvent ( 
info . getMyAssignedName () , 

" Goal Trac ker_Re s ume Moving A tS peed" , 

0.001 , 

None) 
else: 

# look at what the UAV sent us 

# this is where the processing of the knowledge could go. If the 
info the UAS 

# sent back not clear other info could be used 

# for now we kill the lED and delay while it is destroyed 

whoToKill = observations . get (0) . getAssignedName 0 

#whoToKill= str (( UtilityFuncs . getEntityByld( IDofWhoToKill)) . 

getAssignedName ()) 

state . killEntity ( whoToKill , "CATASTROPHlC_KlLL" ) 

UtilityFuncsExp . scheduleEvent ( 
info . getMyAssignedName () , 

" GoalTracker_ResumeMovingAtSpeed" , 

600.0, 

None) 


Name: isResumeMovingAtSpeed 
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224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 

258 

259 

260 

261 

262 

263 

264 


AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

if state . getLastTrigger 0 == " doGoalTracker_ResumeMoving AtSpeed 
_htn_precon_ret=l 


Name: resumeMoving 
AllowMsg: true 
Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

speedToResume = _gt_acti veNode . getVar ( " speedToResume " ) 
UtilityFuncsExp .changeOrderSpeed(info .getMySelf() , speedToResume ) 


Name: modelEvents 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 


Name: isAtControlMeasure 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

if s t ate . getUastTrigger 0 == " doAtAControlMeasure 
_htn_precon_ret=l 


71 










265 

266 

267 

268 

269 

270 

271 

272 

273 

274 

275 

276 

277 

278 

279 

280 

281 

282 

283 

284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 

295 

296 

297 

298 

299 

300 

301 

302 

303 

304 

305 


Name: isAtPhaseLine 
AllowMsg: true 
Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

from cxxi . model . obj ects . holders import CMHolder 
from java, util import Vector 

from cxxi . model . behavior import OrderU ti 1 i t ie s 
cm = state . getLastTriggerParams () [0] 

NAl_phaseLines = _gt_activeNode . getParam ( " NAl_phaseLines " ) 
for i in range ( NAl_phaseLines . size ()) : 
aCMName = NAl_phaseLines . get (i) . getName () 
if aCMName == cm. getName () : 
printMe s s age ( " AT" + s tr (cm. getName ()) , True) 
uasRouteToUse = _gt_activeNode . getParam (" UAS_routes ")[ i ] 
_gt_activeNode .putVar(" uasRouteToUse ", uasRouteToUse) 
_htn_precon_ret=l 


Name: stopAndWait 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

speedToResume = s tate . getCurrentSpeed () 

_gt_activeNode .putVar(" speedToResume " , speedToResume) 
UtilityFuncsExp .changeOrderSpeed(info . getMySelf () ,0.0001) 


Name: dispatchUAS 
AllowMsg: true 
Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 
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306 

307 

308 

309 

310 

311 

312 

313 

314 

315 

316 

317 

318 

319 

320 

321 

322 

323 

324 

325 

326 

327 

328 

329 

330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 

342 

343 


from HTN import UtilityFuncsExp 
printMessage ( " S t art ^UAS^ Tree ", True ) 

#air Route = 

CMHolder. 

retrieveControlMeasureByName ( 

" AlR_CORRlDOR_UAS_NAl_l_ROUTE" ) 

uasRouteToUse = _gt_activeNode . getVar ( " uasRouteToUse " ) 

# set the path to the goal 

goalPath = "HTN/Trees / OperateUAS . xml" 

UtilityEuncsExp . addGoal( 

"BOOOOcOlAl" , 

1 . 0 , 

goalPath , 

[uasRouteToUse , 

_gt_activeNode . getParam(" falsePositiveRate ") , 
_gt_activeNode . getParam( " falseNegativeRate ") ] , 

None) 


Name: isDamageOccured 
AllowMsg: true 
Node Type: DEEAULT 
Is Code Eile: false 
Import: 

Datamap: 

Metadata: 

Code: 

if state . getLastTrigger 0 == " doDamageOccurredlnMyUnit" 
_htn_precon_ret=l 


Name: stopConvoy 
AllowMsg: true 
Node Type: GOAL 
Is Code Eile: false 
Import: 

Datamap: 

Metadata: 

Code: 

from cxxi . model. behavior import 
from java, util import Vector 
#if damage has occured in this 
scenario we are done 


OrderUtilities 

unit we need to stop and for this 
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344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 

361 

362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 

374 

375 

376 

377 

378 

379 

380 

381 

382 

383 


if s tate . isCommander () : 

_htn_precon_ret=l 
prims = Vector () 

prims . add ( Order Utilities . createStopPrimitive () ) 

ord=orders . createOrder( "HTN^P 1 an ^Auto^ Genera ted ", 0.0 , prims ) 

orders . preemptAllOrders (ord) 

simtime = state . getSimTime () 

elapsedTime = (simtime — _gt_activeNode . getVar ( " startTime " ))/60.0 
printMessage ( " mission^ended^after^" + s tr ( elapsedTime ) + "^minutes 
, True) 

# log this run 

logfile = _gt_activeNode . getVar ( " 1 ogfi 1 e " ) 

fnr = _gt_activeNode . getParam ( " falseNegativeRate " ) 

fpr = _gt_activeNode . getParam (" falsePositiveRate " ) 

repNum = _gt_activeNode . getVar ( "repNum" ) 

logfile . write ( ’%d\ t%.2f \ t ’%(repNum , simtime )) 

logfile . write(’Fail\t’) 

logfile . write(’%.2f\t%.2f\t%.2f\n’%( elapsedTime ,fnr ,fpr)) 
logfile . close () 


Name: isStoppedMoving 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

if state . getUastTrigger 0 == " doStoppedMovement" 
_htn_precon_ret=l 


Name: doneWithMission 
AllowMsg: true 
Node Type: GOAL 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

from cxxi. model import CombatXXlModel 
simtime = state . getSimTime () 
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390 
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395 


elapsedTime = (simtime — _gt_acti veNode . get Var ( " s tartTime " ))/6 0.0 
printMessage ( " finished^mission^at^" + s tr ( elapsedTime ) , True) 

# log this run 

logfile = _gt_acti veNode . get Var (" 1 o g fi 1 e " ) 

fnr = _gt_activeNode . getParam ( " falseNegativeRate " ) 

fpr = _gt_activeNode . getParam (" falsePositiveRate " ) 

repNum = _gt_activeNode . getVar ( "repNum" ) 

logfile . write ( ’%d\ t%.2f \ t ’%(repNum , simtime )) 

logfile . write( ’Success\t ’) 

logfile . write) 2f\t%.2f\t%.2f\n’%( elapsedTime ,fnr , fpr)) 
#CombatXXlModel. stopModel ( " run^complete " , 0) 
logfile . close () 
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APPENDIX D: 
OPERATE THE lED HTN 


1 =============================== 

2Name: OperatelED 
3AllowMsg: true 
4Node Type: DEFAULT 

5 Is Code File: false 

6 Import: 

7 Datamap: 

8 sensor = >[Ljava . lang . String ; @66ba60c7 

9 sensorRange = >[Ljava . lang . String ; @5627dd81 

10 targetCount=>[Ljava . lang . String ; @533f6c57 

11 P_K_KIll = >[Ljava . lang . String ; @68elee73 

12 Metadata: 

13Code: 

14 ’’’^Notes 

15_This i s ^a^ tree ^to^operate^a^simple^lED . 

’’ 

17 =============================== 

18 Name: i nit Info 

19 AllowMsg: true 

20 Node Type: DEFAULT 

21 Is Code File: false 

22 Import: 

23 Datamap: 

24 Metadata: 

25 Code: 

26 if _gt_activeNode . getVar ( " i sIni ted " ) == None: 

27 _gt_acti veNode . putVar (" i s I n i t e d " , 1) 

28 _htn_precon_ret=l 

29 =============================== 

30 Name: isReallED 

31 AllowMsg: true 

32 Node Type: DEFAULT 

33 Is Code File: false 

34 Import: 

35 Datamap: 

36 Metadata: 


77 











37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 
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70 
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Code: 


if _gt_activeNode . getParam ( " P_K_K1H " ) > 0.0: 
_htn_precon_ret=l 


Name: startObservation 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

# set the the number of entities that have entered the AOl to zero 
_gt_activeNode .putVar("entitiesEnteredSensorA01" , 0) 
sensor = _gt_activeNode . getParam (" sensor " ) 
sensorRange = _gt_activeNode . getParam (" sensorRange " ) 
sensorObj = obs . getSensorByName ( sensor ) 
sensorObj . setEffectiveRange( sensorRange) 
printMessage( "^^Turning^on^area^sensor ! " , True ) 
if obs . startAOlSensor ( sensor ) : 
sensorObj = obs . getSensorByName ( sensor ) 
printMessage ( "^^AOl^sensor^turned^on" , True) 
else: 

print inf o . getMyAssignedName () ,":^^Cannot^start ^AOl^ Sensor^" 


Name: addReplanTriggers 
AllowMsg: false 
Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

# model events 

goalContainer. getCurrentExecutingStack() . addReplanTrigger(" Entered AOl 

") 

goalContainer. getCurrentExecutingStack() . addReplanTrigger(" 
GoalTracker_DetonateNow" ) 


Name: setlsNotlEDlnfo 
AllowMsg: true 
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76 Node Type: GOAL 

77 Is Code File: false 

78 Import: 

79 Datamap: 

80 Metadata: 

81 Code: 

82 

ince^ t hi s ^i s ^not^an^actual ^lED^—^only^something^ that ^could^be 
confused^as^an 

84^^^^^an^IED ,^it^does^not^need^any^behavior^so^this^tree^can^finish. 

85 __’ ’ ’ 

86 borg . notlED . append ( str (info . getMyAssignedName () )) 

87 printMes s age ( "^ i s ^not ^and^IED" , True) 

88 =============================== 

89 Name: events 

90 AllowMsg: true 

91 Node Type: DEFAULT 

92 Is Code Eile: false 

93 Import: 

94 Datamap: 

95 Metadata: 

96 Code: 

97 =============================== 

98 Name: isGoalTrackerEvent 

99 AllowMsg: true 

100 Node Type: DEEAULT 

101 Is Code Eile: false 

102 Import: 

103 Datamap: 

104 Metadata: 

105 Code: 

106 if s t at e . getLa St Trigger (). s t art s w i t h (" doGoalTracker_ ") : 

107 _htn_precon_ret=l 

108 =============================== 

109 Name: isDetonateNow 

110 AllowMsg: true 

111 Node Type: INTERRUPT 

112 Is Code Eile: false 

113 Import: 

114 Datamap: 

115 Metadata: 
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Code: 

printMessage( "GOAL^TRACKER^EVENT"+ state . getLastTrigger () , True) 
if state . getLastTrigger 0 == " doGoalTracker_DetonateNow " : 
_htn_precon_ret=l 


Name: detonate 
AllowMsg: true 
Node Type: GOAL 
Is Code Lile: false 
Import: 

Datamap: 

Metadata: 

Code: 

from UtilityLuncs import getUniformRandomNumber 

# check to see if we need to kill an entity 
rn = getUniformRandomNumber (0,1.0) 

if rn <= _gt_activeNode . getParam ( " P_K_K1H " ) : 

# the most recent to enter the area is the entity that will be 
killed . 

IDofWhoToKill = s tate . getLastTriggerParams () [0] 
whoToKill= str (( UtilityLuncs . getLntityByld (IDofWhoToKill)) . 
getAssignedName ()) 

state . killLntity ( whoToKill , "CATASTROPHlC_KlLL" ) 

# have the ILD destroy itself 

printMessage ( "lLD^self^destruct^RND^=^" + str(rn), True) 

state . killLntity ( str (info . getMyAssignedName () ) , "CATASTROPHlC_KlLL" ) 


Name: modelLvents 
AllowMsg: true 
Node Type: DLLAULT 
Is Code Lile: false 
Import: 

Datamap: 

Metadata: 

Code: 


Name: isLnteredAOl 
AllowMsg: true 
Node Type: DLLAULT 
Is Code Lile: false 
Import: 
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Datamap: 

Metadata: 

Code: 

if state . getLastTrigger 0 == " doEnteredAOl" 
_htn_precon_ret=l 


Name: entityEnteredAOl 
AllowMsg: false 
Node Type: INTERRUPT 
Is Code Eile: false 
Import: 

Datamap: 

Metadata: 

Code: 

from HTN import UtilityEuncsExp 
import UtilityEuncs 

entitiesEnteredSensorAOl = _gt_activeNode . getVar ( " 
entitiesEnteredSensorAOl") 

entitiesEnteredSensorAOl += 1 

if entitiesEnteredSensorAOl >= _gt_activeNode . getParam ( " targetCount 

printMessage ( "Hello , ^l^am^executing ^the ^isEntered AOl^node^and^ the ^ 
sim^time^ i s : + str ( state . getSimTime ()) , True) 

entitylD = state . getLastTriggerParams ()[ 1 ] 

UtilityEuncsExp . scheduleEvent ( 
info . getMyAssignedName () , 

" GoalTracker_DetonateNow" , 

0.001 , 

entitylD) # pass the id of the entity that my be killed 

else: 

printMessage ( "Not^enough^entities ^im^my^AOl^ye t ", True ) 
_gt_activeNode .putVar(" entitiesEnteredSensorAOl" , 
entitiesEnteredSensorAOl) 
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APPENDIX E: 
OPERATE UAS HTN 


1 =============================== 

2Name: OperateUAS 
3AllowMsg: true 
4Node Type: DEFAULT 

5 Is Code File: false 

6 Import: 

7 Datamap: 

8 route =>cxxi. model. objects . features .CMPolyline 

9 falsePositiveRate=>java . lang .Double 

10 falseNegativeRate=>java . lang . Double 

11 Metadata: 

12Code: 

13 =============================== 

14 Name: initinfo 

15 AllowMsg: true 

16 Node Type: DEFAULT 

17 Is Code File: false 

18 Import: 

19 Datamap: 

20 Metadata: 

21 Code: 

22 if _gt_activeNode . getVar ( " i sIni ted " ) == None: 

23 _gt_acti veNode . putVar (" i s I n i t e d " , 1) 

24 _htn_precon_ret=l 

25 =============================== 

26 Name: addReplanTriggers 

27 AllowMsg: true 

28 Node Type: DEFAULT 

29 Is Code File: false 

30 Import: 

31 Datamap: 

32 Metadata: 

33 Code: 

34 #goalContainer . getCurrentExecutingStack () . addReplanTrigger( 
TakeoffDone" ) 
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53 
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goalContainer. getCurrentExecutingStack() . addReplanTrigger( "HaveLanded 


) 

goalContainer . getCurrentExecutingStack () . addReplanTrigger( " 
EmbarkComplete" ) 

goalContainer . getCurrentExecutingStack () . addReplanTrigger( " 
GoalTracker_CotnpletedEOVScan" ) 


Name: createUASRoutes 
AllowMsg: true 
Node Type: INTERRUPT 
Is Code Eile: false 
Import: 

Datamap: 

Metadata: 

Code: 

from HTN import UtilityEuncsExp 

from cxxi . model. behavior import OrderU ti li tie s 

from java, util import Vector 

from java, util import LinkedHashSet 

from mtry . cxxi . model. HierarchicalTaskNetwork import HTNUtilities 
from cxxi . model. physics . geometry import Direction 
from HTN. Scripts . general import SensorHelpers 
my Transporter = myTransport . getTransporter () 

_gt_activeNode . putVar("myTransporter" , myTransporter) 
allObs = LinkedHashSet () 

_gt_activeNode.putVar("allObs" , allObs) 

# get off the transporter so we can fly our mission 
myTransport. debark () 

route = _gt_activeNode . getParam (" route " ) 
startPoint = state . getCurrentLocation () 
_gt_activeNode.putVar("startPoint" , startPoint) 
prims = Vector!) 

prims . addAll( HTNUtilities . _py_createMovePOsPromRoutes (route , 10.0)) 

prims . add( OrderUtilities . createMovePrimitive ( startPoint , 10.0)) 

prims .add( OrderUtilities . createStopPrimitive ()) 
ord = orders . createOrder ( "HTN^Plan^Auto^Generated " , 0.0, prims) 
orders . addOrder ( ord ) 

printMessage ( "Ready^to^turn^on^UAS,_,sensor " , True) 

UtilityEuncsExp . addGoal( 

info . getMyAssignedName () , 

2.0 , 
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73 "HTN/Trees/UAVSensor. xml" , 

74 [0.0, -45.0,20.0,1000.0,3.5 ,1.0] , 

75 None) 

76 outbound = True 

77 _gt_activeNode . putVar (" outbound " , outbound) 

78 lastDistToEndPoint = 0.0 

79 _gt_activeNode.putVar(" lastDistToEndPoint" , lastDistToEndPoint) 

80 =============================== 

81 Name: events 

82 AllowMsg: true 

83 Node Type: DEFAULT 

84 Is Code File: false 

85 Import: 

86 Datamap: 

87 Metadata: 

88 Code: 

89 =============================== 

90 Name: isGoalTrackerEvent 

91 AllowMsg: true 

92 Node Type: DEFAULT 

93 Is Code File: false 

94 Import: 

95 Datamap: 

96 Metadata: 

97 Code: 

98 if s t at e . getLa St Trigger (). s t art s w i t h (" doGoalTracker_ ") : 

99 _htn_precon_ret=l 

100 =============================== 

101 Name: isCompletedFOVScan 

102 AllowMsg: true 

103 Node Type: INTERRUPT 

104 Is Code File: false 

105 Import: 

106 Datamap: 

107 Metadata: 

108 Code: 

109 if state . getLastTrigger 0 == " doGoalTracker_CompletedFOVScan " : 

110 _htn_precon_ret=l 

111 =============================== 

112 Name: checkSensor 

113 AllowMsg: true 
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Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

# 

# check to see if we are close to the start point in which case we 
do not continue scanning 

currentLoc = state . getCurrentLocation () 

dist = currentLoc . distanceTo (_gt_activeNode . getVar(" startPoint ")) 
outbound = _gt_activeNode . getVar (" outbound " ) 

lastDistToEndPoint = _gt_activeNode . getVar("lastDistToEndPoint") 

# test if we are still outbound 

if outbound and dist < lastDistToEndPoint: 

# we have started back to the landing point 
outbound = False 

_gt_activeNode . putVar( "outbound" , outbound) 
else: 

lastDistToEndPoint = dist 

_gt_activeNode .putVar(" lastDistToEndPoint" , lastDistToEndPoint) 
if dist > 100.0 or outbound: 

UtilityFuncsExp . addGoal( 

info . getMyAssignedName () , 

0.0001 , 

"HTN/Trees/UAVSensor.xml" , 

[0.0,-45.0,30.0,1000.0,3.5,1.0], 

None) 

observations = s tate . getLastTriggerParams () [0] 
allObs = _gt_activeNode . getVar ( " allObs " ) 
allObs . addAll( observations ) 


Name: modelEvents 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 
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171 
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173 

174 
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Name: isHaveLanded 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

if state.getLastTrigger0 == "doHaveLanded 
_htn_precon_ret=l 


Name: UASLanded 
AllowMsg: true 
Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

from cxxi . model . behavior import OrderU ti 1 i t ie s 
from java, util import Vector 
printMessage ( " l^have^landed " , True) 

myTransporter = _gt_acti veNode . getVar ( " myTransporter " 
prims = Vector () 
prims . add ( 

Order Utilities . createBoardEntityPrimitiveByName( 
myTransporter . getAssignedName () )) 

ord=orders . createOrder( "HTN^P 1 an ^Auto^ Genera ted ", 0.0 
orders . addOrder ( ord ) 


Name: isHaveEmbarked 
AllowMsg: true 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

if state . getLastTrigger 0 == " doEmbarkComplete " 
_htn_precon_ret=l 


prims ) 
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Name: doneWithMission 
AllowMsg: false 
Node Type: GOAL 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

from HTN import UtilityFuncsExp 
from java, util import ArrayList 
printMessage(" embarked ^on^ transport ", True ) 
allObs = _gt_activeNode . getVar ( " allObs " ) 
obsList = ArrayListO 

# now process the observations and see if we have anything to report 
for something in allObs: 

aname = something . getAssignedName () 
rn = getUniformRandomNumber (0,1.0) 

printMessage ( " checking^obs^of^" + str (aname) + " ^rnd,_,num^ i s + str 

( rn ) , True ) 

# check to see ground truth if this is an lED 
if borg . notlED . count ( aname ) == 0: 

# this is not in the non—lED list 

if rn > _gt_activeNode . getParam ( " f alseNeg ati veRate " ) : 

# we have correctly identified this as an lED 

# so add it to the observations 

obsList . add ( something) 
else: 

if rn < _gt_ac ti veNode . getParam (" fal s e P o s i ti ve Rat e ") : 

#we think this is an lED so add it to the observations 
obsList . add ( something) 

# tell our transported that we have been loaded 
UtilityPuncsExp . scheduleEvent ( 

_gt_activeNode . getVar("myTransporter") . get AssignedName () , 

"GoalTracker_UASPickedUp" , 

0.001 , 
obsList) 
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APPENDIX F: 
UAV SENSING HTN 


1 =============================== 

2Name; UAVSensor 
SAllowMsg: false 
4Node Type: DEFAULT 

5 Is Code File: false 

6 Import: 

7 Datamap: 

8 sensorAzimuth = >[Fjava . lang . String ; @2831300d 

9 sensorPitch=>[Fjava . lang . String ; @3549bal8 

10 FOVWidth=>[Fjava . lang . String ; @7b5898fc 

11 maxRange = >[Fjava . lang . String ; @75a407a7 

12 meanFOVTime=>[Fjava . lang . String ; @63f2al47 

13 standDevFOVTime = >[ Fj ava . lang . String ; @4e3a6f94 
14Metadata: 

15Code: 

16 ’’’^Notes 

17,_„_„_,This^is^a^simple^model^for^a^sensor^observing ^a^single^Field^of^View . 
’’ 

19 =============================== 

20 Name: i n i 11 n f o 

21 AllowMsg: false 

22 Node Type: DEFAULT 

23 Is Code File: false 

24 Import: 

25 Datamap: 

26 Metadata: 

27 Code: 

28 if _gt_activeNode . getVar ( " i sIni ted " ) == None: 

29 _gt_acti veNode . putVar (" i s I n i t e d " , 1) 

30 _htn_precon_ret=l 

31 =============================== 

32 Name: initsearch 

33 AllowMsg: false 

34 Node Type: DEFAUFT 

35 Is Code File: false 

36 Import: 
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37 Datamap: 

38 Metadata: 

39 Code: 

40 from HTN import UtilityFuncsExp 

41 from UtilityFuncs import getNormalRandomNumber 

42 # 

43 # compute a time to scan this FOR 

44 # 

45 scanTime = getNormalRandomNumber ( _gt_activeNode . getParam ( "meanFOVTime 

) , 

46 _gt_activeNode.getParam(" standDevFOVTime" )) 

47 if scanTime < 1.0: 

48 scanTime = 0.0 

49 _gt_activeNode . putVar (" scanTime " , scanTime) 

50 printMes s age ( " scan^time^ i s + s tr ( scanTime ) , True) 

51 UtilityFuncsExp . scheduleEvent ( 

52 info . getMyAssignedName 0 , 

53 "GoalTracker_StartFOVScan" , 

54 0.001, 

55 None) 

56 =============================== 

57 Name: addReplanTriggers 

58 AllowMsg: false 

59 Node Type: INTERRUPT 

60 Is Code File: false 

61 Import: 

62 Datamap: 

63 Metadata: 

64 Code: 

65 goalContainer . getCurrentExecutingStack () . addReplanTrigger( " 
GoalTracker_StartFOVScan") 

66 goalContainer . getCurrentExecutingStack () . addReplanTrigger( " 
GoalTracker_FOVScanDone" ) 

67 =============================== 

68 Name: events 

69 AllowMsg: false 

70 Node Type: DEFAULT 

71 Is Code File: false 

72 Import: 

73 Datamap: 

74 Metadata: 
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Code: 


Name: isGoalTrackerEvent 
AllowMsg: false 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

if state . getLastTrigger () . startswith ("doGoalTracker_") : 
_htn_precon_ret=l 


Name: isStartFOVScan 
AllowMsg: false 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

if state . getLastTrigger 0 == " doGoalTracker_StartFOVScan 
_htn_precon_ret=l 


Name: scanFOV 
AllowMsg: false 
Node Type: INTERRUPT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

from HTN import UtilityFuncsExp 

from HTN. S cripts . general . SensorHelpers import islnFOV 
from UtilityFuncs import getUniformRandomNumber 
# collect what we can see in this FOV 
from java, util import ArrayList 
observations = ArrayList () 

_gt_activeNode . putVar( " observations " , observations ) 

maxRange = _gt_ac ti veNode . getParam ( " maxRange" ) 

thingsCloseBy =mylntel . getLiveEntitieslnRadius (maxRange * 11) 
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myLocation = state . getCurrentLocation () 

# get the actual sensor orientation 
sensorOrientation = state. getCurrentHeadingO 

sensorOrientation . addDegreesToHeading (_gt_activeNode . getParatn(" 
sensorAzimuth")) 

sensorOrientation . setPitchlnDegrees (_gt_activeNode . getParam(" 
sensorPitch")) 

for something in thingsCloseBy; 

tgtLoc = something . getPhy sicalState 0 . getSynchedLocation ( False ) 
side = something . getSide () 
if str(side) == "BLUE": 
continue 

if islnFOV (tgtLoc , myLocation, sensorOrientation, 

_gt_activeNode . getParam( "FOVWidth" ) , maxRange) : 

# compute probability of seeing 
distToTgt = myLocation . distanceTo (tgtLoc ) 
pObs = 1.0 - (distToTgt/(220)) 
rn = getUniformRandomNumber (0,1.0) 

printMessage ( " In^FOV^" + str ( something . getAssignedName () ) + 
"^^Prob^^detect^is + str(pObs), True) 
if rn < pObs: 

observations . add ( something ) 

printMessage ( " l^saw^" + str ( something . getAssignedName () ) + 
"^^rn^is^" + str(rn). True) 

UtilityFuncsExp . scheduleEvent ( 
info . getMyAssignedName () , 

"GoalTracker_FOVScanDone" , 

_gt_activeNode .getVar(" scanTime " ) , 

None) 


Name: isFOVScanDone 
AllowMsg: false 
Node Type: DEFAULT 
Is Code File: false 
Import: 

Datamap: 

Metadata: 

Code: 

if state . getLastTrigger 0 == " doGoalTracker_FOVScanDone " 
_htn_precon_ret=l 
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187 


Name; scanDone 
AllowMsg: false 
Node Type; GOAL 
Is Code File; false 
Import; 

Datamap; 

Metadata; 

Code; 

from HTN import UtilityFuncsExp 
UtilityFuncsExp . scheduleEvent ( 
info . getMyAssignedName () , 

" GoalTracker_CompletedEOVScan" , 

0.001 , 

_gt_activeNode.getVar(" observations")) 


Name; modelEvents 
AllowMsg; false 
Node Type; DEFAULT 
Is Code Eile; false 
Import; 

Datamap; 

Metadata; 

Code; 


Name; printEvent 
AllowMsg; false 
Node Type; INTERRUPT 
Is Code Eile; false 
Import; 

Datamap; 

Metadata; 

Code; 

printMessage( "EVENT" + state . getLastTrigger () , True) 
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APPENDIX G: 

I ED ONTOLOGY 


l<?xml version= " 1.0 " ?> 


2 

3 

4<!DOCrYPE Ontology 

5 <!ENTITY xsd " 

6 <! ENTITY xml " 

7 <!ENTITY rdfs 

8 <!ENTITY rdf " 


[ 

http: //WWW. w3 . org/2001 /XMLSchema#" > 
http: / /WWW. w3 . org /XML/ 1998/namespace" > 
"http: / /WWW. w3. org/2000/01/ rdf—schema#" > 
http: //WWW. w3 . org/ 1999/02/22 — rdf — syntax —ns#" 


9]> 


> 


10 

11 


12<Ontology xmlns = "http: //www. w3 . org/2002/07/owl#" 

13 xml:base = "http:/ /www. led . com / ontologies / led . owl" 

14 xmlns:rdfs = "http: //www. w3.org/2000/01/rdf—schema#" 

15 xmlns:xsd = "http:/ /www. w3 . org /2 00 1 / XMLSchema#" 

16 xmlns:rdf="http:/ /www. w3. or g/1999/02/22 — rdf —syntax —ns#" 

17 xmlns:xml = "http://www. w3 . org /XML/199 8/ namespace " 

18 ontologyIRl = "http:/ /www. ied . com / ontologies / ied . owl "> 

19 <Prefix name="" 1RI = " h t tp : //www. w3 . org/2002/07/owl#" /> 

20 <Prefix name="owl" IR1 = " http : //www. w3 . org/2002/07/owl#" /> 

21 <Prefix name="rdf" IR1 = " h ttp : //www. w3 . org/1999/02/22 — rdf — syntax—ns#" /> 

22 <Prefix name="xsd" IRI = " h ttp : //www. w3 . org/200 1/XMLSchema#" /> 

23 <Prefix name="rdfs" IRI = " h ttp : //www. w3 . org/2000/0 1 / rdf—schema#" /> 

24 <Annotation> 

25 < AnnotationProperty abbreviatedIRI = " rdfs:comment" /> 

26 <Literal datatypeIRI = "&rdf; PlainLiteral ">An IED ontology that 
describes various lEDs based on different properties that make up an IED 
.</ Literal> 

27 </Annotation> 

28 <Declaration> 

29 <Class IRI = "#Abandoned"/> 

30 </Declaration> 

31 <Declaration> 

32 <Class IRI = "#Batteries "/> 

33 </Declaration> 

34 <Declaration> 
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35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 
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51 
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54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 


<Class 1R1 = 

"#BelowGround" /> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#Cable"/> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#CellPhone"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#Child"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#ChildSBlED "/> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#ConfirmedlED"/> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#DeliveryMethod"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#DetectionMeans"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#DisturbedSoil"/> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#Electric "/> 

</Declaration> 


<Declaration> 


<Class 1R1 = 

"#ElectricCurrent"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#EemaleSBlED"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#Grenade" /> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

" #Human" / > 

</ Declaration> 
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<Declaration> 


<Class 1R1 = 

< / Declaration> 
<Declaration> 

<Class 1R1 = 

< / Declaration> 
<Declaration> 

<Class 1R1 = 
</ Declaration> 
<Declaration> 
<Class 1R1 = 
</ Declaration> 
<Declaration> 
<Class 1R1 = 

< / Declaration> 
<Declaration> 

<Class 1R1 = 

< / Declaration> 
<Declaration> 

<Class 1R1 = 
</ Declaration> 
<Declaration> 
<Class 1R1 = 
</ Declaration> 
<Declaration> 
<Class 1R1 = 

< / Declaration> 
<Declaration> 

<Class 1R1 = 
</ Declaration> 
<Declaration> 
<Class 1R1 = 
</ Declaration> 
<Declaration> 
<Class 1R1 = 

< / Declaration> 
<Declaration> 

<Class 1R1 = 

< / Declaration> 
<Declaration> 

<Class 1R1 = 


#1ED "/> 


#lEDlndicators"/> 


#lsolatedBox"/> 


#Location"/> 


#Magnetic" /> 


#MaleSBlED "/> 


#Man" / > 


#ManWi the ell Phone " / > 


#MetalPlate "/> 


#MiltaryVehicle"/> 


#MouseTrap" /> 


#Munitions "/> 


#NonMilitaryVehicle"/> 


#NonShellMilitary"/> 
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117 
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136 
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</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#Occupied" /> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#OnGround" /> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#Package" /> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#PackagelED" /> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#Physical"/> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#PossiblelED"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#PressurePlate"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#RoundRPG"/> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#RoundSmallArms" /> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#SB1ED "/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#ShellArtillery "/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#ShellMilitary "/> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#ShellMortar"/> 

< / Declaration> 


<Declaration> 
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177 

178 

179 
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<Class 1R1 = 

"#SodaCan"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#Springs " /> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#SteelTubes "/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#StrongBelieflED"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#Touch" /> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#Trigger" /> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#Trip"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#VBlED"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#Vehicle"/> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#Vehicles "/> 

</Declaration> 


<Declaration> 


<Class 1R1 = 

"#Visual"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#WeakBelieflED"/> 

</ Declaration> 


<Declaration> 


<Class 1R1 = 

"#Wires"/> 

< / Declaration> 


<Declaration> 


<Class 1R1 = 

"#Woman" /> 

</ Declaration> 
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<Declaration> 

<ObjectProperty lRl = "#hasDeliveryMethod"/> 

< / Declaration> 

<Declaration> 

<ObjectProperty lRl = "#hasHumanDeliveryMethod" / > 

< / Declaration> 

<Declaration> 

<ObjectProperty lRl = "#haslEDlndicators"/> 

</ Declaration> 

<Declaration> 

<ObjectProperty lRl = "#hasLocation"/> 

</ Declaration> 

<Declaration> 

<ObjectProperty lRl = "#hasPackageDeliveryMethod"/> 

< / Declaration> 

<Declaration> 

<ObjectProperty lRl = "#hasPossibleBelief"/> 
</Declaration> 

<Declaration> 

<ObjectProperty lRl = "#hasTrigger"/> 

</ Declaration> 

<Declaration> 

<ObjectProperty lRl = "#hasVehicleDeliveryMethod"/> 
</ Declaration> 

<Declaration> 

<DataProperty lRl = "#haslEDlndicatorName"/> 

< / Declaration> 

<Declaration> 

<DataProperty lRl = "#isConfirmed"/> 

</ Declaration> 

<Declaration> 

<Namedlndividual 1R1 = "# di s t urb e d s oi 1_ 1 "/> 

</ Declaration> 

<Declaration> 

<Namedlndividual lRl = "#ied_0"/> 

< / Declaration> 

<Declaration> 

<Namedlndividual lRl = "#ied_l "/> 

< / Declaration> 

<Declaration> 

<Namedlndividual lRl = "#ied_2"/> 
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262 
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</ Declaration> 
<Declaration> 


<Namedlndividual lRl = "#ied_3"/> 

< / Declaration> 

<Declaration> 

<Namedlndividual lRl = "#isolatedbox_l "/> 

< / Declaration> 

<Declaration> 

<Namedlndividual lRl = "#wires_l "/> 

</ Declaration> 

<EquivalentClasses> 

<Class lRl = "#ConfirmedlED"/> 

<ObjectlntersectionOf> 

<Class lRl = "#lED"/> 

<DataHasValue> 

<DataProperty lRl = "#isConfirmed"/> 

<Literal datatypelRl = "&xsd ; boolean ">true< / Literal> 
</DataHasValue> 

< / ObjectlntersectionOf> 

</EquivalentClasses> 

<EquivalentClasses> 

<Class lRl = "#lED"/> 

<ObjectlntersectionOf> 

<ObjectSomeValuesErom> 

<ObjectProperty lRl = "#hasDeliveryMethod"/> 

<Class lRl = "#DeliveryMethod" /> 
</ObjectSomeValuesProm> 

<ObjectSomeValuesProm> 

<ObjectProperty lRl = "#haslEDlndicators"/> 

<Class lRl = "#lEDlndicators " /> 
</ObjectSomeValuesProm> 

<ObjectSomeValuesProm> 

<ObjectProperty lRl = "#hasLocation"/> 

<Class lRl = "#Location" /> 

</ObjectSomeValuesProm> 

<ObjectSomeValuesProm> 

<ObjectProperty lRl = "#hasTrigger"/> 

<Class lRl = "#Trigger"/> 

</ObjectSomeValuesProm> 

</Obj ectlntersectionOf> 

</EquivalentClasses> 
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<EquivalentClasses> 

<Class lRl = "#lEDlndicators " /> 

<DataSomeV aluesErom> 

<DataProperty lRl = "#haslEDlndicatorName"/> 

<Datatype abbreviatedlRl = "xsd;string"/> 

</ DataSomeV aluesErom> 

</EquivalentClasses> 

<EquivalentClasses> 

<Class lRl = "#PossiblelED " /> 

<ObjectlntersectionOf> 

<Class lRl = "#lED"/> 

<DataHasValue> 

<DataProperty lRl = "#isConfirmed"/> 

<Literal datatypelRl = "&x sd ; boolean ">false< / Literal> 
</DataHasValue> 

</Obj ectlntersectionOf> 

</EquivalentClasses> 

<EquivalentClasses> 

<Class lRl = "#StrongBelieflED"/> 

<ObjectlntersectionOf> 

<Class lRl = "#PossiblelED " /> 

<ObjectMinCardinality cardinality = "3"> 

<ObjectProperty lRl = "#haslEDlndicators"/> 

<Class lRl = "#lEDlndicators " /> 

< / ObjectMinCardinality> 

</Obj ectlntersectionOf> 

</EquivalentClasses> 

<EquivalentClasses> 

<Class lRl = "#WeakBelieflED"/> 

<ObjectlntersectionOf> 

<Class lRl = "#PossiblelED " /> 

<ObjectMinCardinality cardinality = "l"> 

<ObjectProperty lRl = "#haslEDlndicators"/> 

<Class lRl = "#lEDlndicators " /> 
</ObjectMinCardinality> 

<ObjectMaxCardinality cardinality = "2"> 

<ObjectProperty lRl = "#haslEDlndicators"/> 

<Class lRl = "#lEDlndicators " /> 

</ObjectMaxCardinality> 

</Obj ectlntersectionOf> 

</EquivalentClasses> 
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340 

341 
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343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 

361 

362 


<SubClassOf> 

<Class lRl = "#Abandoned" /> 

<Class lRl = "#Vehicles "/> 

</ SubClassOf> 

<SubClassOf> 

<Class 1R1 = "#B a11eries" /> 

<Class lRl = "#lEDlndicators " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#BelowGround" /> 

<Class lRl = "#Location " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Cable"/> 

<Class lRl = "#Wires"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#CellPhone"/> 

<Class lRl = "#Trigger" /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Child"/> 

<Class lRl = "#Human"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#ChildSBlED"/> 

<Class lRl = "#SBlED"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#ChildSBlED"/> 

< Obj ect Some Value sErom> 

<ObjectProperty 1R1= "#hasHumanDeli very Method 
<Class lRl = "#Child"/> 

</ Obj ec t S ome Values Prom > 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#DisturbedSoil" /> 

<Class lRl = "#lEDlndicators " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Electric " /> 


/> 
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383 
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<Class lRl = "#Wires"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#ElectricCurrent"/> 

<Class lRl = "#Trigger" /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#FemaleSBlED" /> 

<Class lRl = "#SBlED"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#EemaleSBlED" /> 

<ObjectSomeV aluesErom> 

<ObjectProperty 1R1= "#hasHumanDeli very Method " / > 

<Class lRl = "#Woman"/> 

</ObjectSomeValuesErom> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Grenade" /> 

<Class lRl = "#NonShellMilitary"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Human"/> 

<Class lRl = "#DeliveryMethod" /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#lsolatedBox" /> 

<Class lRl = "#lEDlndicators " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Magnetic" /> 

<Class lRl = "#DetectionMeans " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#MaleSBlED"/> 

<Class lRl = "#SBlED"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#MaleSBlED"/> 

<ObjectSomeV aluesErom> 

<ObjectProperty 1R1= "#hasHumanDeli very Method " / > 
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<Class lRl = "#Man"/> 

</ Obj ec t Some Values From > 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Man"/> 

<Class lRl = "#Human"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#ManWi the ell Phone " / > 
<Class lRl = "#lEDlndicators " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#MetalPlate " /> 

<Class lRl = "#lEDlndicators " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#MiltaryVehicle"/> 
<Class lRl = "#Vehicle"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#MouseTrap" /> 

<Class lRl = "#lEDlndicators " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Munitions " /> 

<Class lRl = "#lEDlndicators " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#NonMilitaryVehicle"/> 
<Class lRl = "#Vehicle"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#NonShellMilitary"/> 
<Class lRl = "#Munitions " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Occupied" /> 

<Class lRl = "#Vehicles "/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#OnGround" /> 
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<Class lRl = "#Location " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl="#Package " /> 

<Class lRl = "#DeliveryMethod" /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#PackagelED" /> 

<Class lRl = "#PossiblelED " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#PackagelED" /> 

<ObjectSomeV aluesErom> 

<ObjectProperty lRl="#hasPackageDeliveryMethod"/> 

<Class lRl = "#Package" /> 

</ObjectSomeValuesErom> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Physical" /> 

<Class lRl = "#DetectionMeans " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Pres surePlate " /> 

<Class lRl = "#Trigger" /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#RoundRPG"/> 

<Class lRl = "#NonShellMilitary "/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#RoundSmallArms" /> 

<Class lRl = "#NonShellMilitary "/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#SBlED"/> 

<Class lRl = "#lED"/> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#SBlED"/> 

<ObjectSomeV aluesErom> 

<ObjectProperty 1R1= "#hasHumanDeli very Method " / > 
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504 
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<Class lRl = "#Human" /> 


</ Obj ec t S ome Values From > 
</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#ShellArtillery "/> 

<Class 1R1 = 

"#ShellMilitary "/> 

</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#ShellMilitary "/> 

<Class 1R1 = 

"#Munitions"/> 

</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#ShellMortar"/> 

<Class 1R1 = 

"#ShellMilitary "/> 

</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#SodaCan"/> 

<Class 1R1 = 

"#lEDlndicators"/> 

</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#Springs " /> 

<Class 1R1 = 

"#lEDlndicators"/> 

</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#SteelTubes "/> 

<Class 1R1 = 

"#lEDlndicators"/> 

</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#Touch"/> 

<Class 1R1 = 

"#Trigger" /> 

</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#Trip"/> 

<Class 1R1 = 

"#Wires"/> 

</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#VBlED"/> 

<Class 1R1 = 

"#1ED "/> 

</ SubClassOf> 


<SubClassOf> 


<Class 1R1 = 

"#VBlED"/> 
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< Obj ect Some Value sFrom> 

<ObjectProperty lRl = "#hasVehicleDeliveryMethod"/> 
<Class lRl = "#Vehicle"/> 

</ObjectSomeValuesFrom> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Vehicle"/> 

<Class lRl = "#DeliveryMethod" /> 

</ SubClassOf> 

<SubClassOf> 

<Class 1R1 = "#Vehicles " /> 

<Class lRl = "#lEDlndicators " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Visual"/> 

<Class lRl = "#DetectionMeans " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Wires"/> 

<Class lRl = "#lEDlndicators " /> 

</ SubClassOf> 

<SubClassOf> 

<Class lRl = "#Woman"/> 

<Class lRl = "#Human" /> 

</ SubClassOf> 

<DisjointClasses> 

<Class lRl = "#Abandoned" /> 

<Class lRl = "#Occupied" /> 

< / DisjointClasses> 

<DisjointClasses> 

<Class 1R1 = "#B a11eries" /> 

<Class lRl = "#DisturbedSoil" /> 

<Class lRl = "#lsolatedBox" /> 

<Class lRl = "#ManWi the ell Phone " / > 

<Class lRl = "#MetalPlate " /> 

<Class lRl = "#MouseTrap" /> 

<Class lRl = "#Munitions " /> 

<Class lRl="#SodaCan"/> 

<Class lRl = "#Springs " /> 

<Class lRl = "#SteelTubes " /> 

<Class 1R1 = "#Vehicles " /> 
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<Class lRl = "#Wires"/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#BelowGround" /> 
<Class lRl = "#OnGround" /> 
</DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#Cable"/> 

<Class lRl = "#Electric " /> 

<Class lRl = "#Trip" /> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#CellPhone " /> 

<Class lRl = "#ElectricCurrent"/> 
<Class lRl = "#Pres surePlate " /> 
<Class lRl="#Touch"/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#Child"/> 

<Class lRl = "#Man"/> 

<Class lRl = "#Woman"/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#ChildSBlED"/> 
<Class lRl = "#PemaleSBlED"/> 
<Class lRl = "#MaleSBlED"/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#ConfirmedlED"/> 
<Class lRl = "#PossiblelED " /> 
<Class lRl = "#SBlED"/> 

<Class lRl = "#VBlED"/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#DeliveryMethod" /> 
<Class lRl = "#DetectionMeans " /> 
<Class lRl = "#lED"/> 

<Class lRl = "#lEDlndicators " /> 
<Class lRl = "#Location " /> 

<Class lRl = "#Trigger" /> 

< / DisjointClasses> 
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613 

614 

615 

616 

617 

618 

619 

620 

621 

622 

623 

624 

625 

626 

627 

628 

629 

630 

631 

632 

633 

634 

635 

636 

637 

638 

639 

640 

641 

642 

643 

644 

645 

646 

647 

648 

649 


<DisjointClasses> 

<Class lRl = "#Grenade" /> 

<Class lRl = "#RoundRPG"/> 

<Class lRl = "#RoundSmallArms" /> 
</DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#Human"/> 

<Class lRl="#Package " /> 

<Class lRl = "#Vehicle"/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#Magnetic" /> 

<Class lRl = "#Physical" /> 

<Class lRl = "#Visuar'/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#MiltaryVehicle"/> 

<Class lRl = "#NonMilitaryVehicle"/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#NonShellMilitary "/> 

<Class lRl = "#ShellMilitary "/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#PackagelED"/> 

<Class lRl = "#SBlED"/> 

<Class lRl = "#VBlED"/> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#ShellArtillery "/> 

<Class lRl = "#ShellMortar" /> 

< / DisjointClasses> 

<DisjointClasses> 

<Class lRl = "#StrongBelieflED"/> 

<Class lRl = "#WeakBelieflED"/> 

< / DisjointClasses> 

<ClassAssertion> 

<Class lRl = "#DisturbedSoil" /> 
<Namedlndividual 1R1 = "# di s t urb e d s oi 1_ 1 "/> 

< / ClassAssertion> 

<ClassAssertion> 
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651 

652 

653 

654 
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656 

657 

658 

659 

660 
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683 

684 

685 

686 

687 

688 

689 

690 


<Class lRl = "#lED"/> 

<Namedlndividual lRl = "#ied_0"/> 

< / ClassAssertion> 

<ClassAssertion> 

<Class lRl = "#lED"/> 

<Namedlndividual lRl = "#ied_l "/> 

< / ClassAssertion> 

<ClassAssertion> 

<Class lRl = "#lED"/> 

<Namedlndividual lRl = "#ied_2"/> 

< / ClassAssertion> 

<ClassAssertion> 

<Class lRl = "#lED"/> 

<Namedlndividual lRl = "#ied_3"/> 

< / ClassAssertion> 

<ClassAssertion> 

<Class lRl = "#lsolatedBox" /> 
<Namedlndividual lRl = "#isolatedbox_l "/> 

< / ClassAssertion> 

<ClassAssertion> 

<Class lRl = "#Wires"/> 

<Namedlndividual lRl = "#wires_l "/> 

< / ClassAssertion> 

<ObjectPropertyAssertion> 

<ObjectProperty lRl = "#haslEDlndicators"/> 
<Namedlndividual lRl = "#ied_l "/> 
<Namedlndividual 1R1 = "# di s t urb e d s oi 1_ 1 "/> 
</ObjectPropertyAssertion> 
<ObjectPropertyAssertion> 

<ObjectProperty lRl = "#haslEDlndicators"/> 
<Namedlndividual lRl = "#ied_l "/> 
<Namedlndividual lRl = "#wires_l "/> 
</ObjectPropertyAssertion> 
<ObjectPropertyAssertion> 

<ObjectProperty lRl = "#haslEDlndicators"/> 
<Namedlndividual lRl = "#ied_2"/> 
<Namedlndividual lRl = "#isolatedbox_l "/> 
</ObjectPropertyAssertion> 
<ObjectPropertyAssertion> 

<ObjectProperty lRl = "#haslEDlndicators"/> 
<Namedlndividual lRl = "#ied_2"/> 
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710 

711 

712 
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728 
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731 


<Namedlndividual lRl = "#wires_l "/> 

</ObjectPropertyAssertion> 

<ObjectPropertyAssertion> 

<ObjectProperty lRl = "#haslEDlndicators"/> 
<Namedlndividual lRl = "#ied_2"/> 

<Namedlndividual 1R1 = "# di s t urb e d s oi 1_ 1 "/> 
</ObjectPropertyAssertion> 

<ObjectPropertyAssertion> 

<ObjectProperty lRl = "#haslEDlndicators"/> 
<Namedlndividual lRl = "#ied_3"/> 

<Namedlndividual lRl = "#wires_l "/> 
</ObjectPropertyAssertion> 

<ObjectPropertyAssertion> 

<ObjectProperty lRl = "#haslEDlndicators"/> 
<Namedlndividual lRl = "#ied_3"/> 

<Namedlndividual lRl = "#isolatedbox_l "/> 

</ObjectPropertyAssertion> 

<ObjectPropertyAssertion> 

<ObjectProperty lRl = "#haslEDlndicators"/> 
<Namedlndividual lRl = "#ied_3"/> 

<Namedlndividual 1R1 = "# di s t urb e d s oi 1_ 1 "/> 

</ObjectPropertyAssertion> 

<DataPropertyAssertion> 

<DataProperty lRl = "#haslEDlndicatorName"/> 
<Namedlndividual 1R1 = "# di s t urb e d s oi 1_ 1 "/> 

<Literal datatypelRl = "&xsd; string ">dirt</Literal> 
</DataPropertyAssertion> 

<DataPropertyAssertion> 

<DataProperty lRl = "#isConfirmed"/> 

<Namedlndividual lRl = "#ied_0"/> 

<Literal datatypelRl = "&xsd ; boolean ">false< / Literal> 
</DataPropertyAssertion> 

<DataPropertyAssertion> 

<DataProperty lRl = "#isConfirmed"/> 

<Namedlndividual lRl = "#ied_l "/> 

<Literal datatypelRl = "&xsd ; boolean ">false< / Literal> 
</DataPropertyAssertion> 

<DataPropertyAssertion> 

<DataProperty lRl = "#isConfirmed"/> 

<Namedlndividual lRl = "#ied_2"/> 

<Literal datatypelRl = "&xsd ; boolean ">false< / Literal> 


112 


732 

733 

734 

735 

736 

737 

738 
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749 

750 

751 

752 

753 

754 

755 

756 

757 

758 

759 

760 

761 

762 

763 

764 
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766 

767 

768 

769 

770 

771 

772 


</DataPropertyAssertion> 

<DataPropertyAssertion> 

<DataProperty lRl = "#isConfirmed"/> 

<Namedlndividual lRl = "#ied_3"/> 

<Literal datatypelRl = "&xsd ; boolean ">true< / Literal> 
</DataPropertyAssertion> 

<DataPropertyAssertion> 

<DataProperty lRl = "#haslEDlndicatorName"/> 
<Namedlndividual lRl = "#isolatedbox_l "/> 

<Literal datatypelRl = "&xsd; string ">isolatedbox</Literal> 
</DataPropertyAssertion> 

<DataPropertyAssertion> 

<DataProperty lRl = "#haslEDlndicatorName"/> 
<Namedlndividual lRl = "#wires_l "/> 

<Literal datatypelRl = "&x sd; string ">wires< /Lite ral> 
</DataPropertyAssertion> 

<SubObjectPropertyOf> 

<ObjectProperty lRl = "#hasHumanDeliveryMethod" / > 
<ObjectProperty lRl = "#hasDeliveryMethod"/> 

</ SubObjectPropertyOf> 

<SubObjectPropertyOf> 

<ObjectProperty lRl = "#haslEDlndicators"/> 

<ObjectProperty abbreviatedlRl = "owl;topObjectProperty"/> 
</SubObjectPropertyOf> 

<SubObjectPropertyOf> 

<ObjectProperty lRl = "#hasPackageDeliveryMethod"/> 
<ObjectProperty lRl = "#hasDeliveryMethod"/> 

</ SubObjectPropertyOf> 

<SubObjectPropertyOf> 

<ObjectProperty lRl = "#hasVehicleDeliveryMethod"/> 
<ObjectProperty lRl = "#hasDeliveryMethod"/> 
</SubObjectPropertyOf> 

<EunctionalObjectProperty> 

<ObjectProperty lRl = "#hasLocation"/> 
</EunctionalObjectProperty> 

<ObjectPropertyDomain> 

<ObjectProperty lRl = "#hasDeliveryMethod"/> 

<Class lRl = "#lED"/> 

</Obj ectProperty Domain> 

<ObjectPropertyDomain> 

<Obj ectProperty lRl = "#hasHumanDeliveryMethod"/> 
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806 
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808 

809 

810 
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813 


<Class lRl = "#lED"/> 

</ObjectPropertyDomain> 

<ObjectPropertyDomain> 

<ObjectProperty lRl = "#haslEDlndicators"/> 

<Class lRl = "#lED"/> 

</Obj ectProperty Domain> 

<ObjectPropertyDomain> 

<Obj ectProperty lRl = "#hasLocation"/> 

<Class lRl = "#lED"/> 

</Obj ectProperty Domain> 

<ObjectPropertyDomain> 

<Obj ectProperty lRl = "#hasPackageDeliveryMethod"/> 
<Class lRl = "#lED"/> 

</Obj ectProperty Domain> 

<ObjectPropertyDomain> 

<Obj ectProperty lRl = "#hasPossibleBelief"/> 

<Class lRl = "#lED"/> 

</ObjectPropertyDomain> 

<ObjectPropertyDomain> 

<Obj ectProperty lRl = "#hasTrigger"/> 

<Class lRl = "#lED"/> 

</ObjectPropertyDomain> 

<ObjectPropertyDomain> 

<Obj ectProperty lRl = "#hasVehicleDeliveryMethod"/> 
<Class lRl = "#lED"/> 

</Obj ectProperty Domain> 

<ObjectPropertyRange> 

<Obj ectProperty lRl = "#hasDeliveryMethod"/> 

<Class lRl = "#DeliveryMethod" /> 
</ObjectPropertyRange> 

<ObjectPropertyRange> 

<Obj ectProperty lRl = "#hasHumanDeliveryMethod"/> 
<Class lRl = "#Human" /> 

</ObjectPropertyRange> 

<ObjectPropertyRange> 

<Obj ectProperty lRl = "#hasLocation"/> 

<Class lRl = "#Location " /> 

</ObjectPropertyRange> 

<ObjectPropertyRange> 

<Obj ectProperty lRl = "#hasPackageDeliveryMethod"/> 
<Class lRl="#Package " /> 
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814 </ObjectPropertyRange> 

815 <ObjectPropertyRange> 

816 <Obj ectProperty 1R1 = "#has Pos sibleB elief " /> 

817 <Class lRl = "#PossiblelED"/> 

818 </ObjectPropertyRange> 

819 <Obj ectProperty Range > 

820 <Obj ectProperty lRl = "#hasTrigger " /> 

821 <Class lRl = "#Trigger " /> 

822 </ObjectPropertyRange> 

823 <ObjectPropertyRange> 

824 <Obj ectProperty lRl = "#hasVehicleDeliveryMethod " /> 

825 <Class 1R1 = "# Vehicle " /> 

826 </ObjectPropertyRange> 

827 <FunctionalDataProperty> 

828 <DataProperty lRl = "#haslEDlndicatorName " /> 

829 </EunctionalDataProperty> 

830 <EunctionalDataProperty> 

831 <DataProperty lRl = "#isConfirmed " /> 

832 </EunctionalDataProperty > 

833 <DataPropertyDomain> 

834 <DataProperty lRl = "#haslEDlndicatorName " /> 

835 <Class lRl = "#lEDlndicators" /> 

836 </DataPropertyDomain> 

837 <DataPropertyDomain> 

838 <DataProperty lRl = "#isConfirmed " /> 

839 <Class lRl = "#lED"/> 

840 </DataPropertyDomain> 

841 <DataPropertyRange> 

842 <DataProperty lRl = "#haslEDlndicatorName " /> 

843 <Datatype abbreviatedlRl = " xsd: string " /> 

844 </DataPropertyRange> 

845 <D ataPropertyRange> 

846 <DataProperty lRl = "#isConfirmed " /> 

847 <Datatype abbreviatedlRl = " xsd;boolean " /> 

848 </DataPropertyRange> 

849</ Ontology> 

850 

851 

852 

853 <!— Generated by the OWL API (version 3.4.2) http: //owlapi.sourceforge. net 

—> 


115 


THIS PAGE INTENTIONALLY LEET BLANK 


116 



LIST OF REFERENCES 


[1] U. S. Army, COMBATXXI Users Guide, U.S. Army WSMR, n.d. 

[2] T. Mauer et al., “Search and detection modeling of military imaging systems,” in Proc. 
SPIE 5784, Infrared Imaging Systems: Design, Analysis, Modeling, and Testing XVI, 

201, Orlando, Florida, 2005, pp. 201-215. 

[3] 1. Balogh et al., “Using hierarchical task networks to create dynamic behaviors in combat 
models,” unpublished. 

[4] S. C. for Biomedical Informatics Research. What Is Protege? The National Center for 
Biomedical Ontology. (2013). [Online]. Available: 

http ://protege. Stanford. edu/aboutus/aboutus. html 

[5] U. Staff, Eyes of the Army, U.S. Army Unmanned Aircraft Systems Roadmap 2010-2035, 
U.S. Army UAS Center of Excellence, Fort Rucker, Alabama, n.d. 

[6] J. Gertler, “U.S. unmanned aerial systems,” Congressional Research Service, CSR Report 
for Congress R42136, Jan. 2012. 

[7] Raven overview, (2013). [Online]. Available: 
http://www.avinc.com/downloads/Raven_Gimbal.pdf 

[8] Raven UAS launch, (2013). [Online]. Available: 
http://www.avinc.com/img/media_gallery/UAS_Raven_Field_Launch.jpg 

[9] Kestrel - land mti for small unmanned aircraft systems, (2013). [Online]. Available: 
http://www.avinc.com/uas/kestrel/ 

[10] U. A. Force, “U.S. Air Force scan eagle fact sheet,” (2013). [Online]. Available: http: 
//www.af.mil/AboutUs/FactSheets/Display/tabid/224/Article/104532/scan-eagle.aspx 

[11] AAI unmanned aircraft systems. Shadow RQ-7B System Data Sheet. Hunt Valley, MD, 

2012. 

[12] Shadow 200 rq-7 tactical unmanned aircraft system. United States of America. [Online]. 
Available: 

http://www.army-technology.eom/projects/shadow200uav/shadow200uav3.html 

[13] General atomics aeronautical. Gray Eagle Armed Persistence Data Sheet. Poway: CA, 
G.A.A.S.I., 2012. 

[14] General atomics awarded $30m gray eagle contract. (2012). [Online]. Available: 
http://www.unmanned.co.uk/unmanned-vehicles-news/ 

unmanned-aerial-vehicles-uav-news/general-atomics-awarded-30m-gray-eagle-contract/ 


117 




[15] U.S. Air Force mq-9 reaper fact sheet. (2010). [Online]. Available: http: 

//ww w. af. mil/AboutU s/FactS heets/Display/tabid/224/Article/104470/mq- 9- reaper, aspx 

[16] MQ-9 reaper, photo: Air force, (2012). [Online]. Available: 
http://www.wired.com/dangerroom/2012/04/killer-drone-upgrade/training-to-hunt/ 

[17] U.S.J.C. of Staff, Joint Publication 3-07.2 Antiterrorism, Department of Defense, 
Washington, D.C. 

[18] Faces of the fallen. (2013). [Online]. Available: 
http://apps.washingtonpost.com/national/fallen/causes-of-death/ied/ 

[19] U. A. Training and Doctrine, FM 3-24.2 Tactics in Counterinsurgency, Headquarters 
Department of the Army, Washington, D.C. 

[20] C. Shepherd, “Methods for ied reconnaissance and detection,” vol. 113, p. not cited, 
Sep./Oct. 2004. 

[21] R. H. Vollmerhausen and E. Jacobs, “The targeting task performance (ttp) metric a new 
model for predicting target acquisition performance,” Modeling and Simulation Division 
Night Vision and Electronic Sensors Directorate, VA, Tech. Rep. AMSEE-NV-TR-230, 
Aug. 2004. 

[22] O. H. Schade, “Optical and photoelectric analog of the eye,” J. Opt. Soc. Am., vol. 46, 
no. 9, pp. 721-738, Sep 1956. [Online]. Available: 
http://www.opticsinfobase.org/abstract.cfm?URI=josa-46-9-721 

[23] Night vision and electronic sensors directorate history. (2013). [Online]. Available: 
http://www.nvl.army.mil/history.html 

[24] Thermal imaging: how far can you see it? data sheet. (2013). [Online]. Available: 
http://www.flir.com/uploadedfiles/eng_01_howfar.pdf 

[25] B. O’Kane et ah, “Cycle criteria for detection of camouflaged targets,” DTIC Document, 
Tech. Rep., 2005. 

[26] C. J. Darken, “Computer graphics-based models of target detection: Algorithms, 
comparison to human performance, and failure modes,” The Journal of Defense 
Modeling and Simulation: Applications, Methodology, Technology, vol. 4, no. 3, pp. 
262-276, 2007. [Online]. Available: http://dms.sagepub.eom/content/4/3/262.abstract 

[27] E. Baez, “Target acquisition methods in combat simulations,” unpublished. 

[28] E. D. Sacerdoti, “A structure for plans and behavior,” DTIC Document, Tech. Rep., 1975. 

[29] S. S. J. A. Baier and S. A. Mcllraith, “Htn planning with preferences.” 


118 



[30] I. Balogh et al., “Use of hierarchical task networks to model complex operational tasks in 
combatxxi(PowerPoint Presentation),” 80th Military Operations Research Society 
Symposium, Mission Area Analysis Branch, 3300 Russell Road Quantico, VA, June 
11-14, 2012. 

[31] R. Brachman and H. Levesque. (2003.) "Knowledge representation and reasoning". 
[Online]. Available: http://www.cin.ufpe.br/~mtcfa/files/inl 122/Knowledge% 
20Representation%20and%20Reasoning.pdf 

[32] R. Davis et al.,“What Is a Knowledge Representation,” AIMagazine, vol. 14, no. 1, pp. 
17-33, 1993. 

[33] V. Mehta, D. Patel, and N. Reddy. History of knowledge representation. (2008). [Online]. 
Available: http://www.knowledgerep.info/history.html 

[34] K. Klement. Propositional logic: History. (2005). [Online]. Available: 
"http://www.iep.utm.edU/prop-log/#H2" 

[35] G. Luger, Artificial Intelligence: Structures and Strategies for Complex Problem Solving. 
Boston, MA: Addison-Wesley, 2009. 

[36] A. Collins and M. Quillian, “Retrieval time from semantic memory,” Journal of Verbal 
Learning and Verbal Behavior, vol. 8, no. 2, pp. 240-247, 1969. 

[37] Merriam-Webster. Merriam-webster. (2013). [Online]. Available: 
http://www.merriam-webster.com/dictionary/ontology 

[38] C. Childers, “Applying semantic web concepts to support net-centric warfare using the 
tactical assessment markup language TAML,” M. S. thesis. Department of Computer 
Science, Naval Postgraduate School, Monterey, CA, 2006. 

[39] TRAC-Monterey, “Deployable force protection scenario,” unpublished. 

[40] I. Balogh, “UAV sensor model,” PowerPoint Slide, Naval Postgraduate School, Monterey, 
CA, Aug 2013. 

[41] W.W.W. Consortium. Owl web ontology language overview, introduction. (2004). 
[Online]. Available: http://www.w3.org/TR/2004/REC-owl-features-20040210/ 

[42] Semantic reasoner. (2013). [Online]. Available: 
"http://en.wikipedia.org/wiki/Semantic_reasoner" 

[43] M. Horridge. A practical guide to building owl ontologies using protege 4 and co-ode 
tools edition 1.3. (2011). [Online]. Available: "http://owl.cs.manchester.ac.uk/tutorials/ 
protegeowltutorial/resources/ProtegeOWLTutorialP4_v 1_3 .pdf" 


119 



[44] J. Johnson, “Analysis of image forming systems,” presented at the Image Intensifier 
Symposium, Warfare Vision Branch, Electrical Engineering Dept., U.S. Army Engineer 
Research and Development Eaboratories, 1958. 


120 



INITIAL DISTRIBUTION LIST 


1. Defense Technical Information Center 
Ft. Belvoir, Virginia 

2. Dudley Knox Library 
Naval Postgraduate School 
Monterey, California 


121 




